Bugzilla

Hi Arthur,

The point of this bug is not so much about using or not using offline support, but rather the slow speed of Thunderbird to load caldav calendar with thousand of items, as it happens every time you start TB with or without offline support and the **high number of network requests** and the **lengthy time** required to for response parsing/ui populating. While calendar perf has improved over the past year, it still not great in regards to this bug.

(In reply to Arthur K. (he/him) from comment #67)
> (In reply to benedikt.kaless from comment #66)
> > I can confirm this issue. In our medium sized organisation with 150 employees we face a lot of frustration currently due to "slowness" of Thunderbird if you subscribe to more than 5-10 calendars. 

@benedikt.kaless what do you mean by "slowness"? Is it at startup? Or afterwards during TB usage?
It is quite impressive that you can use  5-10 calendars at a time, as not long ago that would crawl TB or make it unresponsive for minutes or bring it in an unusable state.

In recent betas (currently on 132.0b4 (64-bit)) I did notice some slowness in the UI interface, delay when you type on keyboard, select recipient, click on action button, drag&drops... Etc though I cannot say if it is linked to using multiple calendars. Startup perf is also not bad as I can quickly access email... While calendars load in the backgrounds, but I have only five network calendar and only a couple with thousands of items. There three more I access less often that I keep disabled for performance reason.

> And offline support is enabled for all of these calendars? That should improve perf since it'll only need to fetch and new changes. 

The problem we noticed happen especially at TB startup when the calendar offline support cache is re-populated from scratch and all items from all network calendars are loaded at the same time making TB slow and unusable for a while because is all done within the same TB process (main interface, email, calendars, etc) all at the same time, "interfering" with each other.

> Network drivers fully up to date?

It is not a network drivers problem it is a design problem with the calendaring infrastructure in TB.** Ideally each calendar or group of calendar shall be loaded in separate process from the main UI/email one**... So calendars would load in the background without causing overall TB performance issues. **Ideally also each calendar shall be fully loaded in couple of network request max**, in Web browser it only takes 1s to load a full calendar file via https, 1mn+ for the same calendar via caldav in TB. And that is just for one calendar, problem gets worth as you add more network calendars... Not the point of this bug but good to be aware of :-)

(In reply to benedikt.kaless from comment #68)
> Due to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1694709 offline-support is not activated for all those calendars because events are vanishing in a calendar using offline support.

I can confirm as well, though I haven't yet noticed recently in TB 128.3.1, it is too early to tell as it happens randomly. A way to fix it is do disable offline support, and re-enable it, so missing items re-appear as the full calendar is reloaded in cache. The main problem being that event disappearing/missing are not necessarily noticed by end-users as it happens silently, so it causes them to miss meetings double book them, etc... That also the reason we disabled offline support for network calendars in organisations we support as online calendar is the most reliable. Not the point of this bug but good to be aware of :-)

Regards,

Hi Arthur,

The point of this bug is not so much about using or not using offline support, but rather the slow speed of Thunderbird to load caldav calendar with thousand of items, as it happens every time you start TB with or without offline support and the **high number of network requests** and the **lengthy time** required to for response parsing/ui populating. While calendar perf has improved over the past year, it still not great in regards to this bug.

(In reply to Arthur K. (he/him) from comment #67)
> (In reply to benedikt.kaless from comment #66)
> > I can confirm this issue. In our medium sized organisation with 150 employees we face a lot of frustration currently due to "slowness" of Thunderbird if you subscribe to more than 5-10 calendars. 

@benedikt.kaless what do you mean by "slowness"? Is it at startup? Or afterwards during TB usage?
It is quite impressive that you can use  5-10 calendars at a time, as not long ago that would crawl TB or make it unresponsive for minutes or bring it in an unusable state.

In recent betas (currently on 132.0b4 (64-bit)) I did notice some slowness in the UI interface, delay when you type on keyboard, select recipient, click on action button, drag&drops... Etc though I cannot say if it is linked to using multiple calendars. Startup perf is also not bad as I can quickly access email... While calendars load in the backgrounds, but I have only five network calendar and only a couple with thousands of items. There three more I access less often that I keep disabled for performance reason.

> And offline support is enabled for all of these calendars? That should improve perf since it'll only need to fetch and new changes. 

The problem we noticed happen especially at TB startup when the calendar offline support cache is re-populated from scratch and all items from all network calendars are loaded at the same time making TB slow and unusable for a while because is all done within the same TB process (main interface, email, calendars, etc) all at the same time, "interfering" with each other.

> Network drivers fully up to date?

It is not a network drivers problem it is a design problem with the calendaring infrastructure in TB.** Ideally each calendar or group of calendar shall be loaded in separate process from the main UI/email one**... So calendars would load in the background without causing overall TB performance issues. **Ideally also each calendar shall be fully loaded in couple of network request max**, in Web browser it only takes 1s to load a full calendar file via https, 1mn+ for the same calendar via caldav in TB. And that is just for one calendar, problem gets worth as you add more network calendars... Not the point of this bug but good to be aware of :-)

(In reply to benedikt.kaless from comment #68)
> Due to this bug 1694709 offline-support is not activated for all those calendars because events are vanishing in a calendar using offline support.

I can confirm as well, though I haven't yet noticed recently in TB 128.3.1, it is too early to tell as it happens randomly. A way to fix it is do disable offline support, and re-enable it, so missing items re-appear as the full calendar is reloaded in cache. The main problem being that event disappearing/missing are not necessarily noticed by end-users as it happens silently, so it causes them to miss meetings double book them, etc... That also the reason we disabled offline support for network calendars in organisations we support as online calendar is the most reliable. Not the point of this bug but good to be aware of :-)

Regards,