Home > Web Apps > Kronolith Performance Problem

Kronolith Performance Problem

September 17th, 2009 Leave a comment Go to comments

I use Kronolith all over the place. It’s part of the Horde application suite. It is basically a very featureful calendar server and I like it a lot. Having said that, I use it pretty much exclusively from Sunbird/Lightning because the web-interface still needs a little work in my opinion. Nonetheless it’s very good.

The Problem.
I recently rolled it out at work along with the rest of the Horde webmail suite (and some extras and tweaks), and immediately ran into a problem. I imported the CEO’s calendar without a hitch, but as soon as I tried to access it via the RPC .ics file link (i.e. via Sunbird) I discovered the problem – it was taking forever to spit the file out. I discovered I could duplicate the problem from anywhere and it always took about 50 seconds between asking for the .ics file and actually receiving it.

After MANY hours trying to debug the problem, finally resulting in using the Zend xdebug extension to produce a call-graph with time information that I could view in KCacheGrind I discovered that those 50 seconds were pretty much ALL spent in php::iconv_substr, from calls made in Horde’s String.php.

The bottom line is, in order to wrap strings to conform to the .ics file standard specification, the developers created their own wordwrap function instead of using PHP’s own wordwrap function because the latter wouldn’t do line-folding in the way required by the specification. The problem is, the Horde developers’ version is extremely inefficient in comparison to the PHP version. This hasn’t really cropped up before because (I guess) not a lot of people put much information in the “Description” section of events. Thing is, the CEO’s PA had been filling out the Description field with a duplicate of the Location and Date information along with anything else that was relevant and a long end-line that was just symbols. With all of this text to wordwrap into .ics file standard using an inefficient wordwrap function, it took forever – well 50 seconds anyway.

The Solution.
Solution the first: get the PA to stop duplicating information that was already a core part of the event object anyway and try to limit the use of the Description field. Obviously that’s not much of a solution, but I’m certain it will make a good amount of difference.

The actual solution, is simply to dump the Horde developers’ wordwrap function in favour of the native PHP function. This does make for .ics files that are not quite standards compliant, but so far I haven’t had any clients complain or fail to function properly with them. I don’t like it, but if I have to choose between standards compliance with a 50s load time and very slight non-compliance with a 3s load time, I know which I’m going to pick every time.

The change itself is tiny. Find lib/Horde/iCalendar.php and head to around line 1055. It’s line 1055 in Horde Groupware Webmail Edition v1.2.3, but it may be slightly different in your version.

Remove or comment out the lines:

$attr_string = String::wordwrap($attr_string, 75, $this->_newline . ' ',
                                true, 'utf-8', true);

and replace with:

$attr_string = wordwrap($attr_string, 75, $this->_newline . ' ', true);

et voilá.

I don’t believe the developers plan on fixing this problem in the Horde H3 (version 3) tree, but I am assured that they are refactoring the code for Horde 4 which should take care of it.

Categories: Web Apps Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).