[CalendarServer-users] Re: Performance

Andreas Brodbeck dassi at hispeed.ch
Tue Jul 3 00:42:50 PDT 2007


In article <CE6E2C9414D8F6DC5BE98214 at caldav.corp.apple.com>,
 Cyrus Daboo <cdaboo at apple.com> wrote:

> Hi Andreas,
> 
> --On July 2, 2007 2:22:44 AM +0200 Andreas Brodbeck 
> <dassi at hispeed.ch> 
> wrote:
> 
> > I have a test setup here, and I observe quite a long "calculation time"
> > for report queries. I have some few dates in the calendar, including
> > reccurent dates. It typically takes up to 500ms to give me a time range
> > for 30 days (equals to approx. 30 events) or so. (On a really fast
> > server machine). And for a whole year it takes up seconds...
> >
> > How can I speed up this? What are the performance issues in general?
> > What is this load-balancing thing in the config file?
> >
> > Any help is very much appreciated! (Thanks to Apple having this Calendar
> > Server open source!)
> >
> 
> Can you describe exactly what the query is you are doing (i.e. send the XML 
> report body)? I would like to know if its just a time-range query or 
> whether it also does some text-matching. Also, I want to know whether you 
> are requesting the calendar-data to be returned with the report and whether 
> you are returning all the data or just part of it. The other question is 
> how large is the calendar you are targeting the report at? i.e. how many 
> resources in it?
> 

Hi Cyrus


Here is the report I am querying the calendar folder with:

<cal:calendar-query xmlns:dav="DAV:" 
xmlns:cal="urn:ietf:params:xml:ns:caldav">
  <dav:prop>
    <dav:getetag/>
    <cal:calendar-data>
      <cal:expand end="20070802T000000Z" start="20070703T000000Z"/>
      <cal:comp name="VCALENDAR">
        <cal:allprop/>
        <cal:comp name="VEVENT">
          <cal:allprop/>
        </cal:comp>
        <cal:comp name="VTIMEZONE">
          <cal:allcomp/>
          <cal:allprop/>
        </cal:comp>
      </cal:comp>
    </cal:calendar-data>
  </dav:prop>
  <cal:filter>
    <cal:comp-filter name="VCALENDAR">
      <cal:comp-filter name="VEVENT">
        <cal:time-range end="20070802T000000Z" start="20070703T000000Z"/>
      </cal:comp-filter>
    </cal:comp-filter>
  </cal:filter>
</cal:calendar-query>


My observations are:

If I only have 1 single normal event, it takes 120ms, as shown in the 
access.log:

/principals/users/admin/ [03/Jul/2007:07:20:54 +0000] "REPORT 
/calendars/users/user_5/calendar/ HTTP/1.1" 207 1983 "-" "-" [120.7 ms]

If I only have 1 single *recurrent* event, which occurs daily within the 
range of 30 days, it takes 350 ms:

/principals/users/admin/ [03/Jul/2007:07:26:36 +0000] "REPORT 
/calendars/users/user_5/calendar/ HTTP/1.1" 207 16711 "-" "-" [352.0 ms]



And querying the empty (!) inbox needs 60ms:

<cal:calendar-query xmlns:dav="DAV:" 
xmlns:cal="urn:ietf:params:xml:ns:caldav">
  <dav:prop>
    <dav:getetag/>
    <cal:calendar-data>
      <cal:comp name="VCALENDAR">
        <cal:allprop/>
        <cal:comp name="VEVENT">
          <cal:allprop/>
        </cal:comp>
        <cal:comp name="VTIMEZONE">
          <cal:allcomp/>
          <cal:allprop/>
        </cal:comp>
      </cal:comp>
    </cal:calendar-data>
  </dav:prop>
  <cal:filter>
    <cal:comp-filter name="VCALENDAR">
      <cal:comp-filter name="VEVENT">
      </cal:comp-filter>
    </cal:comp-filter>
  </cal:filter>
</cal:calendar-query>

/principals/users/admin/ [03/Jul/2007:07:20:54 +0000] "REPORT 
/calendars/users/user_5/inbox/ HTTP/1.1" 207 69 "-" "-" [67.5 ms]



> Some things to note: a time-range only query should utilize only the sqlite 
> database and so ought to be fast. If you include any property/parameter 
> text searches then it will slow down a lot as currently we don't index 
> calendar text data - in that case the server has to open and search each 
> resources. Obviously that is far from ideal and we will be adding a lot 
> more indexing in the future to aid with that.


> 
> The other issue is returning partial calendar again - again to do that the 
> server has to open and parse each resource that is matched by the query, 
> and then write them up via a filter that only includes the selected 
> properties etc. Writing the entire calendar data is a lot easier - it just 
> streams the entire "raw" resource data from disk to the network. Whilst it 
> might be possible to utilize the index for the partial data case, a better 
> first step would be to optimize the iCalendar parser/generator.

In my query, what can I do to get all the raw data as fast as possible? 
As far as I remember right, I needed to explicitly list the <cal:comp> 
tags in the <cal:calendar-data> area. The single <cal:allcomp/> did not 
seem to work. What is the syntax in the report to tell the server to 
give me ALL the data just as is? 


Thanks for your help!

Andreas



More information about the calendarserver-users mailing list