1266146 - Lightning pegs CPU for >3 minutes on TB startup when subscribed to many iCalendar feeds

Status: RESOLVED DUPLICATE of bug 1502923

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[WalterGR]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

1.  Subscribe to many iCalendar feeds in Lightning.
2.  Close Thunderbird.
3.  Start Thunderbird.



Actual results:

Thunderbird does not respond to user interaction for more than 3 minutes.

Breaking that down a bit:

Thunderbird pegs a CPU during startup.  The UI isn't displayed until 20 seconds of this.  After the UI is displayed, it continues to peg a CPU for around 3 minutes.

During this time, TB does not respond to user interaction.

This happens whether a Calendar tab was open during the last session (and hence is restored during startup) or not.

Further, it occasionally pegs a CPU and becomes unresponsive for extended periods of time periodically after startup.


Expected results:

The TB UI is displayed immediately and responds to user interaction immediately.  The UI remains responsive throughout the session.

Comment 1

[WalterGR]

I have attempted to gather profiling data without success.

1.  The Gecko Profiler extension described on https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G does not behave as described: no UI is displayed anywhere in Thunderbird.  (Even if it were, it's unlikely to be of any use since the UI is unresponsive while TB is pegging a CPU.)

2.  During the period of time that TB is pegging a CPU, it does not respond to remote debugging connections from Firefox.

Comment 2

[Wayne Mery (:wsmwk)]

Thanks for trying. Yeah, I think I also had determined the profiler UI isn't working in 45 and determined exactly when it broke.

The good news is, we have plenty of reports of performance issues :)

Comment 3

[WalterGR]

What can I do to help debug the issue?  Or make this bug easier to fix?

TB freezing for minutes at a time makes it... difficult... to use.

Comment 4

[[:MakeMyDay]]

Where are those calendars located? On a webserver or are these local/network files? If on webservers, do you know wtherer these servers supporting etag/last-modified headers? Is offline-support enabled for those calendars in Lightning? Does that only happen at TB startup or also later when a timebased syncing happens again?

I'm currently not sure whether our mechanism to prevent unneccessary sync operations also take effect at TB startup time.

Apart of that, it is advised to close and restart TB on a regular basis instead of running it forever (and hibernating instead of shutting down the system) as the ics provider is known to have a memory leak which will increase memory consumption over time until getting irresponsive in worst case - see bug 1192209. Also, it is a good idea to make the sync interval as large a possible for those calendars, especcially if have multiple ics calendars to lower the effect of that bug.

Comment 5

[WalterGR]

> Where are those calendars located? On a webserver or are these local/network files?

Web server.

> If on webservers, do you know wtherer these servers supporting etag/last-modified headers? 

I don't know.

The majority of the calendar feeds are on meetup.com.  Here is a sample:

*   http://api.meetup.com/balisp/upcoming.ical (208 bytes)
*   http://api.meetup.com/The-Bay-Area-Clojure-User-Group/upcoming.ical (2,858 bytes)
*   http://api.meetup.com/SF-Bay-Area-UX-UI-Design/upcoming.ical (10,018 bytes)

> Is offline-support enabled for those calendars in Lightning? 

Yes.

> Does that only happen at TB startup or also later when a timebased syncing
> happens again?

As above, it happens both at startup and later.

> Also, it is a good idea to make the sync interval as large a possible for
> those calendars, especcially if have multiple ics calendars to lower the
> effect of that bug.

I've done this.  (Of course it goes without saying that choosing between having timely information or a UI that doesn't frequently lock up for 3 minutes - is a poor choice.)