Hi Arthur, Geoff, (In reply to Richard Leger from comment #49) > (In reply to Arthur K. (he/him) from comment #47) > > (In reply to Geoff Lankow (:darktrojan) from comment #43) > > > The number of events in a single request is set by the pref `calendar.caldav.multigetBatchSize` and the default is 100. You could try increasing that, but your server may not like it. > > > > I know this will sound counterintuitive but I am wondering what happens if he DECREASES calendar.caldav.multigetBatchSize to something like 50. So I tried to modify the multigetBatchSize to 120,300,1000,20... but in all case the calendar is slow to load... - if you increase the number, the number of request reduce but the time it takes to process each request increases... - if you reduce the number, the number of request increase, but the time to take to process them reduce but because they are so numerous it still takes time to process them... 500-700ms to process each request seems rather long! Mostly due to Receiving part... I noticed in the attachment that at multigetBatchSize 20, after the PROFIND request, with the first REPORT request that follows, TB takes 35s to read the entire response from the server (or cache)... what is identified as Receiving time in the request Timing. This may suggest that TB is struggling to parse the XML from the server response somehow... In dev tool the XML response is truncated as too big to display on screen... but maybe the issue is that XML parser form TB... or the time/performance required to process data when received... something looks wrong here... So until that is fixed, I don't think that changing multigetBatchSize would be a solution for now. But it may have helped highlight the possible problem... maybe something in the response is making the XML parser to chock somehow... or TB processing is not fast enough... but that is clearly not normal I believe... each other request still seems to take a long time to process as well despite size of response reduce to a 20 items per response. First REPORT Request highlighted in attachment: ```` <?xml version="1.0" encoding="UTF-8"?> <sync-collection xmlns="DAV:"><sync-token/><sync-level>1</sync-level><prop><getcontenttype/><getetag/></prop></sync-collection> ```` Response: ```` <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>/davical/caldav.php/richard/home/4a711f90-49e5-49d2-8b0b-c81302e03a47.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vevent</getcontenttype> <getetag>"0d90149af381b9e7bb640a6bc013ff9e"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/25266cf7-8e99-4e74-9213-31e703b930e8.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"73861aadb01741916ef2abac26bd1a7d"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/0f197419-8762-43a0-b702-8a4a07b10845.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"98cf6c57df838a99c10a733c77c2c097"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/a1585803-b2ee-45a0-b6f6-cc03ccf022b9.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"1ca23baae75fb8717e390a08e7e42a8a"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> (...) ```` Is the format of the response supposed to look like the above? Is the content of each item loaded (including Description/Attachments) as part or reading the Response? I don't see such request in the DevTools networking... Description/Attachments/Attendees info loading would not need to happen at startup... if that is the case and the reason why Response is read/parsed slowly... Hope that help. Regards,
Bug 1543953 Comment 51 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hi Arthur, Geoff, (In reply to Richard Leger from comment #49) > (In reply to Arthur K. (he/him) from comment #47) > > (In reply to Geoff Lankow (:darktrojan) from comment #43) > > > The number of events in a single request is set by the pref `calendar.caldav.multigetBatchSize` and the default is 100. You could try increasing that, but your server may not like it. > > > > I know this will sound counterintuitive but I am wondering what happens if he DECREASES calendar.caldav.multigetBatchSize to something like 50. So I tried to modify the multigetBatchSize to 120,300,1000,20... but in all case the calendar is slow to load... - if you increase the number, the number of request reduce but the time it takes to process each request increases... - if you reduce the number, the number of request increase, but the time to take to process them reduce but because they are so numerous it still takes time to process them... 500-700ms to process each request seems rather long! Mostly due to Receiving part... I noticed in the attachment that at multigetBatchSize 20, after the PROFIND request, with the first REPORT request that follows, TB takes 35s to read the entire response from the server (or cache)... what is identified as Receiving time in the request Timing. This may suggest that TB is struggling to parse the XML from the server response somehow... In dev tool the XML response is truncated as too big to display on screen... but maybe the issue is that XML parser form TB... or the time/performance required to process data when received... something looks wrong here... So until that is fixed, I don't think that changing multigetBatchSize would be a solution for now. But it may have helped highlight the possible problem... maybe something in the response is making the XML parser to chock somehow... or TB processing is not fast enough... but that is clearly not normal I believe... each other request still seems to take a long time to process as well despite size of response reduce to a 20 items per response. First REPORT Request highlighted in attachment: ```` <?xml version="1.0" encoding="UTF-8"?> <sync-collection xmlns="DAV:"><sync-token/><sync-level>1</sync-level><prop><getcontenttype/><getetag/></prop></sync-collection> ```` Response: ```` <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>/davical/caldav.php/richard/home/4a711f90-49e5-49d2-8b0b-c81302e03a47.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vevent</getcontenttype> <getetag>"0d90149af381b9e7bb640a6bc013ff9e"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/25266cf7-8e99-4e74-9213-31e703b930e8.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"73861aadb01741916ef2abac26bd1a7d"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/0f197419-8762-43a0-b702-8a4a07b10845.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"98cf6c57df838a99c10a733c77c2c097"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/davical/caldav.php/richard/home/a1585803-b2ee-45a0-b6f6-cc03ccf022b9.ics</href> <propstat> <prop> <getcontenttype>text/calendar; component=vtodo</getcontenttype> <getetag>"1ca23baae75fb8717e390a08e7e42a8a"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> (...) ```` Is the format of the response supposed to look like the above? Is the content of each item loaded (including Description/Attachments) as part of Receiving (as per Request/Response Timing)? I don't see any separate request in the DevTools Networking that show how each item data is loaded... Description/Attachments/Attendees info loading would not need to happen at startup... if that is the case and the reason why Response is read/parsed slowly... Hope that help. Regards,