Does timezones have to be so slow?
Hi, I'm experiencing slow REPORT/calendar-query responses on medium large calendars. calendarserver is spending a lot of time adding VTIMEZONE components to VEVENTS - and sadly it seems to be the same calculations done every time (all events are the same timezone). tzinfo is cached by vobject (helped by timezones.py), but the settzinfo method on TimezoneComponent is still doing the same job again and again. It would seem obvious to me to cache TimezoneComponent objects, maybe with a validity tag, which gives you the valid timerange for this VTIMEZONE component. This might also help get around the problem that vobject only expands timezone defs from 2000 to 2030 Any gotcha, I've overlooked which explains why TimezoneComponents are not already cached? /P
Hi Peter, --On April 21, 2010 9:55:21 AM +0200 Peter Mogensen <apm@one.com> wrote:
I'm experiencing slow REPORT/calendar-query responses on medium large calendars. calendarserver is spending a lot of time adding VTIMEZONE components to VEVENTS - and sadly it seems to be the same calculations done every time (all events are the same timezone). tzinfo is cached by vobject (helped by timezones.py), but the settzinfo method on TimezoneComponent is still doing the same job again and again.
It would seem obvious to me to cache TimezoneComponent objects, maybe with a validity tag, which gives you the valid timerange for this VTIMEZONE component. This might also help get around the problem that vobject only expands timezone defs from 2000 to 2030
Any gotcha, I've overlooked which explains why TimezoneComponents are not already cached?
Can you send the full request body for the calendar-query REPORTs that you are using so I can take a look at this? -- Cyrus Daboo
Cyrus Daboo wrote:
Can you send the full request body for the calendar-query REPORTs that you are using so I can take a look at this?
Sorry for forgetting to CC the list. To sum up: REPORT(calendar-query) requests with an empty <calendar-data/> element will read events directly from disk an be relatively fast. If <calendar-data/> is non-empty, there will be instantiated python-vobject objects to handle the returned data. This will result in a VTIMEZONE (TimezoneComponent) object being created for each event and even though the tzinfo is cached, creating theses objects is pretty costly. The constructor for vobject/icalendar.py TimezoneComponent will call settzinfo(),getTransition(), and the localy defined test() which in turn calls tzinfo.dst() - where most of the request time is spent. This should be possible to optimize since the resulting VTIMEZONEs are often the exact same for all VEVENTs. Sending an empty caldendar-data in the request is much faster though. Thanx to Cyrus. /Peter
participants (2)
-
Cyrus Daboo
-
Peter Mogensen