Open Bug 588952 Opened 14 years ago Updated 4 months ago

autosync should use new async folder opening to avoid extremely bad performance at startup or when reading messages with very big IMAP folders (like gmail All Mail)

Categories

(MailNews Core :: Backend, defect)

1.9.2 Branch
x86
All
defect

Tracking

(Not tracked)

People

(Reporter: ehsan.akhgari, Unassigned)

References

(Blocks 4 open bugs)

Details

(Keywords: perf, Whiteboard: [tbperf-key][has stack trace])

Attachments

(1 file)

So I have this major problem with Thunderbird 3.1.2.  As I'm reading messages from an imap folder, sometimes Thunderbird starts consuming 100% of the CPU.  I've sharked it multiple times, and I get a stack similar to this every time:

http://pastebin.mozilla.org/771644

I'm not sure what the source of the problem is, but I thought I'd file a bug anyways...
Thunderbird doesn't use ctypes BTW, does it?  The "ffi" there reminds me of libffi.
Sid would know.
We don't use ctypes at all in Thunderbird 3.1 (Mozilla 1.9.2). We do use it in trunk, but only for test code right now.

Do you know what the unresolved symbols in the stack are all about?

(ccing asuth, who is our perf expert I believe)
I'm with sid; it seems like that stack involves a lot of wild guesses owing to a lack of symbols.  I'm not sure how to get a build with good symbols other than just building your own thunderbird from comm-1.9.2.  (I don't think we build shark nightlies like firefox does; I see none in our nightly tree, at least.)

I will take the opportunity, however, to make wild accusations about extensions being at fault.  You don't, perchance, have anything like one of those bugzilla extensions that hooks into message display and involves a request of bugzilla?
Switch to a nightly build - they should have symbols
(In reply to comment #4)
> I'm with sid; it seems like that stack involves a lot of wild guesses owing to
> a lack of symbols.  I'm not sure how to get a build with good symbols other
> than just building your own thunderbird from comm-1.9.2.  (I don't think we
> build shark nightlies like firefox does; I see none in our nightly tree, at
> least.)

We do.
(In reply to comment #4)
> I'm with sid; it seems like that stack involves a lot of wild guesses owing to
> a lack of symbols.  I'm not sure how to get a build with good symbols other
> than just building your own thunderbird from comm-1.9.2.  (I don't think we
> build shark nightlies like firefox does; I see none in our nightly tree, at
> least.)

I'm using a stock build.  Shouldn't those have symbols (for crash reporting, for example)?

I'm also not sure why I need a Shark build...

> I will take the opportunity, however, to make wild accusations about extensions
> being at fault.  You don't, perchance, have anything like one of those bugzilla
> extensions that hooks into message display and involves a request of bugzilla?

I do have the Bugmail extension installed.  Was that only an accusation or was it coming from experience?  (It was kind of too accurate for a mere accusation... ;-) )
(In reply to comment #7)
> I'm using a stock build.  Shouldn't those have symbols (for crash reporting,
> for example)?

Crash symbols are resolved server-side.  It's possible for other code to get at those symbols, but I don't think Shark is mozilla/breakpad aware and the output of what you provided seemed destructive about the symbol offsets.  I think direct invocation of shark (rather than via the process thing) can let you save stuff so we don't lose the addresses, but I don't know of any tools that can do the magic required right now...
 
> I'm also not sure why I need a Shark build...

Well, just something with symbols in it/accessible to the mac toolchain.  A build with the mozilla shark hooks to trigger it on demand is not required.  Bit of an overloaded term I guess.
 
> I do have the Bugmail extension installed.  Was that only an accusation or was
> it coming from experience?  (It was kind of too accurate for a mere
> accusation... ;-) )

We don't really do all that much on message display, whereas extensions might potentially do things that cause gecko to go into script blocker mode, do synchronous I/O or XHR's, etc.
OK, grabbed a 1.9.2 nightly and profiled it.  This is the profile:

http://pastebin.mozilla.org/772403

It's mork.  It doesn't look like anything extension-related to me at all.
(In reply to comment #9)
> It's mork.

Haha.

(That is all.)
I'm guessing you have a very very large imap folder, with 10's of thousands of messages or more, and IMAP autosync is kicking in and trying to sync that folder. GMail All Mail is a popular one for that. If you turn off offline storage of the folder, this problem should go away...
Should we convert this bug into an enhancement request to have autosync use the new async folder opening logic?
I've already done so. In my mind :-)
I just ran Linkai in safe mode just to make sure, and the exact same problem happened again.

Here's some more details:

I also get this at startup.  When I start Thunderbird for the first time, it takes about 5 minutes before it's usable, and Thunderbird spends all that time with 100% CPU usage with the same profile.  After that, when I'm reading my emails, it happens from time to time, and each time it takes 10-20 seconds to over a minute.  I've noticed that this happens more often when I'm going through a bunch of emails and marking them as read quickly, but that may just be my imagination.
(In reply to comment #11)
> I'm guessing you have a very very large imap folder, with 10's of thousands of
> messages or more, and IMAP autosync is kicking in and trying to sync that
> folder. GMail All Mail is a popular one for that. If you turn off offline
> storage of the folder, this problem should go away...

Well, that is certainly the case.  My All Mail folder currently has 148,000+ unread emails, but I never even look at that folder.  My Bugzilla folder, where I spend most of my time, has 116,000+ emails in total.
I turned off offline storage for my All Mail folder (which has 381,000+ messages) to see if it helps.
yeah, i was going to bump up my guess to over 100,000 when you mentioned 5 minutes at startup. If you're reading a folder, we leave the DB open, so once you pay the price of opening your bugzilla folder, you won't pay the price again. But autosync will run around and periodically check folders like All Mail.

5 minutes at startup is still horribly excessive. That makes me think we're opening the All Mail folder at startup. You could try a MSGDB log with timestamps to see what's happening at startup:

https://wiki.mozilla.org/MailNews:Logging
Warranty void! Warranty void!
(In reply to comment #18)
> Warranty void! Warranty void!

lol!
So here's the stack trace of what happens at startup when opening my All Mail folder:

http://pastebin.mozilla.org/772429
Summary: Extremely bad performance when reading messages → Extremely bad performance at startup or when reading messages with very big IMAP folders
So, David helped me figure out the cause of the Startup issue.  My All Mail folder was set as the Trash folder, which caused Thunderbird to set the flag on that folder, which apparently takes 5 minutes for me.  :-)

With that setting changed, I don't take the startup hit.  But autosync should still be an issue.  I'll profile again when I see this issue.
This just happened again, this time with different stuff higher on the stack:

http://pastebin.mozilla.org/772464
ah, ok, that'll happen every hour. If you see yet an other stack trace, please link to it.

Perhaps we should have a setting that says there are no purge settings for a folder, so we wouldn't have to open the db. But that might be time better spent switching to sqlite.
also citing mork is bug 589310
Here's another profile I took from a similar hang which looks like database purging:

# Report 1 - Session 1 - Time Profile of thunderbird-bin
SharkProfileViewer
# Generated from the visible portion of the outline view
+ 82.6%, morkArray::CutSlot(morkEnv*, int), thunderbird-bin
| + 82.6%, morkTable::CutRow(morkEnv*, morkRow*), thunderbird-bin
| | + 82.6%, morkBuilder::OnNewRow(morkEnv*, morkPlace const&, morkMid const&, unsigned char), thunderbird-bin
| | | + 82.6%, morkParser::ReadRow(morkEnv*, int), thunderbird-bin
| | | | + 82.6%, morkParser::ReadTable(morkEnv*), thunderbird-bin
| | | | | + 82.6%, morkParser::ReadContent(morkEnv*, unsigned char), thunderbird-bin
| | | | | | + 82.6%, morkParser::ReadGroup(morkEnv*), thunderbird-bin
| | | | | | | + 82.6%, morkParser::ReadAt(morkEnv*, unsigned char), thunderbird-bin
| | | | | | | | + 82.6%, morkParser::ReadContent(morkEnv*, unsigned char), thunderbird-bin
| | | | | | | | | + 82.6%, morkParser::OnPortState(morkEnv*), thunderbird-bin
| | | | | | | | | | + 82.6%, morkParser::ParseLoop(morkEnv*), thunderbird-bin
| | | | | | | | | | | + 82.6%, morkParser::ParseMore(morkEnv*, int*, unsigned char*, unsigned char*), thunderbird-bin
| | | | | | | | | | | | + 82.6%, morkThumb::DoMore(morkEnv*, unsigned int*, unsigned int*, unsigned char*, unsigned char*), thunderbird-bin
| | | | | | | | | | | | | + 82.6%, morkThumb::DoMore(nsIMdbEnv*, unsigned int*, unsigned int*, unsigned char*, unsigned char*), thunderbird-bin
| | | | | | | | | | | | | | + 82.6%, nsMsgDatabase::OpenMDB(char const*, int), thunderbird-bin
| | | | | | | | | | | | | | | + 82.6%, nsMsgDatabase::Open(nsILocalFile*, int, int), thunderbird-bin
| | | | | | | | | | | | | | | | + 82.6%, nsMsgDBService::OpenFolderDB(nsIMsgFolder*, int, nsIMsgDatabase**), thunderbird-bin
| | | | | | | | | | | | | | | | | + 82.6%, nsImapMailFolder::GetDatabase(), thunderbird-bin
| | | | | | | | | | | | | | | | | | + 82.6%, nsMsgDBFolder::ApplyRetentionSettings(int), thunderbird-bin
| | | | | | | | | | | | | | | | | | | + 82.6%, nsMsgDBFolder::ApplyRetentionSettings(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | + 82.6%, nsImapMailFolder::ApplyRetentionSettings(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | + 82.6%, nsMsgPurgeService::PerformPurge(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsTimerImpl::Fire(), libxpcom_core.dylib
| | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsTimerEvent::Run(), libxpcom_core.dylib
| | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsThread::ProcessNextEvent(int, int*), libxpcom_core.dylib
| | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, NS_ProcessPendingEvents_P(nsIThread*, unsigned int), libxpcom_core.dylib
| | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsBaseAppShell::NativeEventCallback(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsAppShell::ProcessGeckoEvents(void*), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, __CFRunLoopDoSources0, CoreFoundation
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, __CFRunLoopRun, CoreFoundation
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, CFRunLoopRunSpecific, CoreFoundation
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, CFRunLoopRunInMode, CoreFoundation
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, RunCurrentEventLoopInMode, HIToolbox
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, ReceiveNextEventCommon, HIToolbox
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, BlockUntilNextEventMatchingListInMode, HIToolbox
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, _DPSNextEvent, AppKit
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:], AppKit
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, -[NSApplication run], AppKit
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsAppShell::Run(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, nsAppStartup::Run(), thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, XRE_main, thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, main, thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 82.6%, _start, thunderbird-bin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |   82.6%, start, thunderbird-bin
- 15.6%, morkTable::CutRow(morkEnv*, morkRow*), thunderbird-bin
- 0.2%, morkMap::Get(morkEnv*, void const*, void*, void*, unsigned char**), thunderbird-bin
- 0.2%, morkParser::NextChar(morkEnv*), thunderbird-bin
- 0.1%, morkParser::FindGroupEnd(morkEnv*), thunderbird-bin
- 0.1%, morkAtomBodyMap::Equal(morkEnv*, void const*, void const*) const, thunderbird-bin
  0.1%, unix_syscall, mach_kernel
- 0.1%, morkParser::ReadRow(morkEnv*, int), thunderbird-bin
- 0.1%, morkParser::ReadCell(morkEnv*), thunderbird-bin
- 0.1%, morkMap::Cut(morkEnv*, void const*, void*, void*, unsigned char**), thunderbird-bin
- 0.0%, morkZone::ZoneZapRun(morkEnv*, void*), thunderbird-bin
- 0.0%, morkTable::MaybeDirtySpaceStoreAndTable(), thunderbird-bin
- 0.0%, morkStore::MidToOid(morkEnv*, morkMid const&, mdbOid*), thunderbird-bin
- 0.0%, morkRowMap::Hash(morkEnv*, void const*) const, thunderbird-bin
- 0.0%, morkRowMap::Equal(morkEnv*, void const*, void const*) const, thunderbird-bin
- 0.0%, morkParser::ReadHex(morkEnv*, int*), thunderbird-bin
- 0.0%, morkMap::get_assoc(void*, void*, int) const, thunderbird-bin
- 0.0%, lseek, libSystem.B.dylib
- 0.0%, js_NextActiveContext(JSRuntime*, JSContext*), libmozjs.dylib
- 0.0%, copyout_kern, mach_kernel
- 0.0%, blkclr, mach_kernel
- 0.0%, vnode_fsnode, mach_kernel
- 0.0%, vm_pageclean_setup, mach_kernel
- 0.0%, vm_page_lookup, mach_kernel
- 0.0%, utf8_encodelen, mach_kernel
- 0.0%, upl_commit_range, mach_kernel
- 0.0%, uio_resid, mach_kernel
- 0.0%, uio_addiov, mach_kernel
- 0.0%, sqlite3Step, libsqlite3.dylib
- 0.0%, sqlite3PagerGetExtra, libsqlite3.dylib
- 0.0%, sqlite3_user_data, libsqlite3.dylib
- 0.0%, spec_strategy, mach_kernel
- 0.0%, pthreadMutexEnter, libsqlite3.dylib
- 0.0%, morkRowMap::GetOid(morkEnv*, mdbOid const*), thunderbird-bin
- 0.0%, morkRow::TakeCells(morkEnv*, morkCell*, unsigned int, morkStore*), thunderbird-bin
- 0.0%, morkRow::MergeCells(morkEnv*, morkCell*, unsigned int, unsigned int, unsigned int), thunderbird-bin
- 0.0%, morkRow::CountOverlap(morkEnv*, morkCell*, unsigned int), thunderbird-bin
- 0.0%, morkParser::ReadValue(morkEnv*), thunderbird-bin
- 0.0%, morkParser::ReadMid(morkEnv*, morkMid*), thunderbird-bin
- 0.0%, morkNode::morkNode(unsigned char), thunderbird-bin
- 0.0%, morkIntMap::Equal(morkEnv*, void const*, void const*) const, thunderbird-bin
- 0.0%, morkBuilder::OnNewCell(morkEnv*, morkPlace const&, morkMid const*, morkBuf const*), thunderbird-bin
- 0.0%, morkBookAtom::EqualFormAndBody(morkEnv*, morkBookAtom const*) const, thunderbird-bin
- 0.0%, ml_set_interrupts_enabled, mach_kernel
- 0.0%, memcmp, libSystem.B.dylib
- 0.0%, mac_thread_userret, mach_kernel
- 0.0%, mac_policy_list_conditional_busy, mach_kernel
- 0.0%, mac_file_check_change_offset, mach_kernel
  0.0%, lo_unix_scall, mach_kernel
- 0.0%, lck_mtx_unlock_darwin10, mach_kernel
- 0.0%, IOMemoryDescriptor::getLength() const, mach_kernel
- 0.0%, IOMedia::getProvider() const, IOStorageFamily
- 0.0%, IOGeneralMemoryDescriptor::dmaCommandOperation(unsigned long, void*, unsigned int) const, mach_kernel
- 0.0%, IOBlockStorageDriver::breakUpRequest(unsigned long long, IOMemoryDescriptor*, IOStorageCompletion, IOBlockStorageDriver::Context*), IOStorageFamily
- 0.0%, inval_copy_windows, mach_kernel
- 0.0%, hfs_vnop_strategy, mach_kernel
- 0.0%, hfs_owner_rights, mach_kernel
- 0.0%, hfs_file_is_compressed, mach_kernel
- 0.0%, fp_drop, mach_kernel
- 0.0%, flush_tlb64, mach_kernel
- 0.0%, device_pager_setup, mach_kernel
- 0.0%, copyin_kern, mach_kernel
- 0.0%, cluster_pageout, mach_kernel
- 0.0%, _rtc_nanotime_read, mach_kernel
- 0.0%, __bzero, libSystem.B.dylib
Well, here is the same profile in a useful format: http://pastebin.mozilla.org/775136
Ehsan, what are your results of comment 16?
Component: Mail Window Front End → Backend
Product: Thunderbird → MailNews Core
QA Contact: front-end → backend
Version: 3.1 → 1.9.2 Branch
(In reply to comment #27)
> Ehsan, what are your results of comment 16?

It fixed the problem for me, in the sense that it now happens a lot less frequently.  But I think we should still keep this bug open.
Wayne pinged me on this over IRC, which reminded me that I did follow some gmail/Thunderbird integrations tutorials on the web, so setting the trash folder to All Mail may be coming from one of them...
(In reply to comment #12)
> Should we convert this bug into an enhancement request to have autosync use the
> new async folder opening logic?
(In reply to comment #13)
> I've already done so. In my mind :-)

adjusting summary, and add startup meta bug.

now, we need an assignee :)
Severity: normal → major
Depends on: 570582
OS: Mac OS X → All
Summary: Extremely bad performance at startup or when reading messages with very big IMAP folders → autosync should use new async folder opening to avoid extremely bad performance at startup or when reading messages with very big IMAP folders (like gmail All Mail)
gmail isn't the focus of this bug, but it just occurred to me, if you have the gmail "All mail" folder subscribed, is there a reason you haven't unsubscribed?   Because we recommend that in https://support.mozillamessaging.com/en-US/kb/Thunderbird-and-Gmail#w_synchronizing-messages
I have not seen this recently, and I currently do not subscribe to my All Mail folder...
I am getting this constantly right now. I'm not sure if it's the same stack, since all of Ehsan's pastebins seem to have expired. But my stacks are always for opening my gmail All Mail folder.

I'm actually not sure how I ended up subscribed to All Mail. I certainly have never wanted to be.
David can you look at the stack ?
Whiteboard: [has stack trace]
Ludo, it's just opening a large db. We know that's slow. We use All Mail as the archive folder, so it leads to smoother integration if we're subscribed to it. https://bugzilla.mozilla.org/show_bug.cgi?id=729504#c2 will help you figure out if it's all mail that's getting opened when your hang happens. I don't know why we would constantly be re-opening it or syncing it, unless you have a high amount of traffic into your gmail account, and have check all folders for new mail set.
Cc'ing atuljangra.
Blocks: tbbigfolder
Blocks: 561272
Whiteboard: [has stack trace] → [tbperf-key][has stack trace]

Ben, thus far the async open has not been utilized. Given what you've seen so far in your backend work, is there anything to suggest a) that we shouldn't do this to alleviate some of our performance issues, and b) are there any backend changes that should be done before this is attempted?

Flags: needinfo?(benc)

I'm not sure what you mean by async folder opening. There is nsIMsgDatabase.asyncOpenFolderDB() for opening the msgdb. Is that what you meant?
asyncOpenFolderDB() doesn't appear to be used anywhere currently (other than in a couple of unit tests), so I'd be a little wary of it.
Stepping back a little, if it's the msgdb that's the speed bottleneck, then I'd say that real issue is that it's too slow (for whatever reason). The locally-stored db of metadata should be lightening-quick (relatively!) to open/scan. Even if you've got colossal quantities of email, it should really be on the order of seconds, not minutes...
Anyway - have we got replication steps for this one? If I set up a dummy local IMAP server with huge quantities of emails, do you think that would trigger it? Are we sure it's IMAP-only?

Flags: needinfo?(benc)

(In reply to Ben Campbell from comment #38)

I'm not sure what you mean by async folder opening. There is nsIMsgDatabase.asyncOpenFolderDB() for opening the msgdb. Is that what you meant?

Yes

asyncOpenFolderDB() doesn't appear to be used anywhere currently (other than in a couple of unit tests), so I'd be a little wary of it.

Yes, it would be wise to proceed cautiously, especially if we don't have tests in this area.

Stepping back a little, if it's the msgdb that's the speed bottleneck, then I'd say that real issue is that it's too slow (for whatever reason). The locally-stored db of metadata should be lightening-quick (relatively!) to open/scan. Even if you've got colossal quantities of email, it should really be on the order of seconds, not minutes...

Yes, async is a workaround for improving the speed of opening the meta - but there's no other choice AFAIK until some distant future date when the backend gets reworked. In the mean time (including the past decade), message stores have on average gotten considerably bigger and we haven't improved our methods/performance in this area to keep pace.

Anyway - have we got replication steps for this one? If I set up a dummy local IMAP server with huge quantities of emails, do you think that would trigger it? Are we sure it's IMAP-only?

Yes, it would be imap-only - born out of https://wiki.mozilla.org/MailNews:Better_Faster_IMAP_Plan and Bug 470624 - RFE: On-demand Auto-Sync. Note however, the request for this feature (i.e. this bug 588952) predates the version 3 concept of autosync for better faster imap, which is partly driven to service to gloda search ... where we also have Bug 551209 - Gloda should asynchronously enter/open folders during indexing

I'm not aware of a testcase. I would think your idea of triggering should work. Jcranmer or Gene might have thoughts.

Flags: needinfo?(gds)
Flags: needinfo?(Pidgeot18)
See Also: → 470624

TB starts up fine for me even with lots of test accounts and messages. Debug trunk builds are a bit slower, as expected. I usually have several folder scattered around with 17000+ messages and those don't cause a problem.
I want to get back to looking at the copying of large number of messages between imap accounts and to local so maybe I'll notice something that causes a major slowdown, but I doubt it.

Flags: needinfo?(gds)
See Also: → 899913
Flags: needinfo?(Pidgeot18)

(In reply to gene smith from comment #40)

TB starts up fine for me even with lots of test accounts and messages. Debug trunk builds are a bit slower, as expected. I usually have several folder scattered around with 17000+ messages and those don't cause a problem.
I want to get back to looking at the copying of large number of messages between imap accounts and to local so maybe I'll notice something that causes a major slowdown, but I doubt it.

The comments suggest this is more likely to be visible at 100k messages and more.

(In reply to Wayne Mery (:wsmwk) from comment #39)

(In reply to Ben Campbell from comment #38)

...
Stepping back a little, if it's the msgdb that's the speed bottleneck, then I'd say that real issue is that it's too slow (for whatever reason). The locally-stored db of metadata should be lightening-quick (relatively!) to open/scan. Even if you've got colossal quantities of email, it should really be on the order of seconds, not minutes...

Yes, async is a workaround for improving the speed of opening the meta - but there's no other choice AFAIK until some distant future date when the backend gets reworked. In the mean time (including the past decade), message stores have on average gotten considerably bigger and we haven't improved our methods/performance in this area to keep pace.

Anyway - have we got replication steps for this one? If I set up a dummy local IMAP server with huge quantities of emails, do you think that would trigger it? Are we sure it's IMAP-only?

Yes, it would be imap-only - born out of https://wiki.mozilla.org/MailNews:Better_Faster_IMAP_Plan and Bug 470624 - RFE: On-demand Auto-Sync. Note however, the request for this feature (i.e. this bug 588952) predates the version 3 concept of autosync for better faster imap, which is partly driven to service to gloda search ... where we also have Bug 551209 - Gloda should asynchronously enter/open folders during indexing

I'm not aware of a testcase. I would think your idea of triggering should work. Jcranmer or Gene might have thoughts.

Rereading the bug report, I'm inclined to think db load is not the core issue and that async open would only help a little. I suspect the high mork activity seen by Ehsan was more symptom than cause, and the more likely cause is imap. Ref comment 11, comment 16, and comment 35. I also recall that Ehsan had server side filters, and we know from other reports that imap syncing related to server side filters can be costly.

We don't have all of Ehsan's traces but perhaps another possible factor is automatic compact, because compact can happen immediately on startup (AFAIK not delayed, unlike the purge service which delays itself on startup by 5 minutes). We might determine whether this is true, and determine the possible impact.

Comment 23 and comment 25 cite nsMsgPurgeService related to retention settings. The purge service should not greatly impact startup because the code states "if we've spent more than .5 seconds in this loop, don't apply any more retention settings because it might lock up the UI." - ref https://searchfox.org/comm-central/rev/dfafa758b061c4b4052899dd51d4304c066b249f/mailnews/base/src/nsMsgPurgeService.cpp#111 Those comments also state the purge service should not be invoked until 5 minutes after startup, which could clearly happen 5 minutes into Ehsan's "long startup". Also interesting is purge is invoked during "compact all folders" - which I had not known - but I think that is not the same as automatic compact. (purge checking every 5 minutes seems excessive, but that's a different matter)

Flags: needinfo?(gds)

(In reply to Wayne Mery (:wsmwk) from comment #41)

(In reply to gene smith from comment #40)

TB starts up fine for me even with lots of test accounts and messages. Debug trunk builds are a bit slower, as expected. I usually have several folder scattered around with 17000+ messages and those don't cause a problem.
I want to get back to looking at the copying of large number of messages between imap accounts and to local so maybe I'll notice something that causes a major slowdown, but I doubt it.

The comments suggest this is more likely to be visible at 100k messages and more.

(In reply to Wayne Mery (:wsmwk) from comment #39)

(In reply to Ben Campbell from comment #38)

...
Stepping back a little, if it's the msgdb that's the speed bottleneck, then I'd say that real issue is that it's too slow (for whatever reason). The locally-stored db of metadata should be lightening-quick (relatively!) to open/scan. Even if you've got colossal quantities of email, it should really be on the order of seconds, not minutes...

Yes, async is a workaround for improving the speed of opening the meta - but there's no other choice AFAIK until some distant future date when the backend gets reworked. In the mean time (including the past decade), message stores have on average gotten considerably bigger and we haven't improved our methods/performance in this area to keep pace.

Anyway - have we got replication steps for this one? If I set up a dummy local IMAP server with huge quantities of emails, do you think that would trigger it? Are we sure it's IMAP-only?

Yes, it would be imap-only - born out of https://wiki.mozilla.org/MailNews:Better_Faster_IMAP_Plan and Bug 470624 - RFE: On-demand Auto-Sync. Note however, the request for this feature (i.e. this bug 588952) predates the version 3 concept of autosync for better faster imap, which is partly driven to service to gloda search ... where we also have Bug 551209 - Gloda should asynchronously enter/open folders during indexing

I'm not aware of a testcase. I would think your idea of triggering should work. Jcranmer or Gene might have thoughts.

Rereading the bug report, I'm inclined to think db load is not the core issue and that async open would only help a little. I suspect the high mork activity seen by Ehsan was more symptom than cause, and the more likely cause is imap. Ref comment 11, comment 16, and comment 35. I also recall that Ehsan had server side filters, and we know from other reports that imap syncing related to server side filters can be costly.

however, comment 12 and comment 13 suggest async open as the solution (btw, the purge code comments indicate purge is also invoked on folder open.)

Flags: needinfo?(benc)

Sounds like fundamental problems in areas I've never tread, e.g., sync vs. async of autosync. However, with many messages in a folder the time to open the folder can get long due to having to fetch the folder flags for every message. The use of imap CONDSTORE can help in this regard but it's disabled by default. A while back a user had a problem and enabling CONDSTORE and fixed the "time to open large folder" problem. I had to make some tweaks to the code for it to work but don't remember what they were. Then again, this may be another problem and not the same as this bug.

Flags: needinfo?(gds)
Flags: needinfo?(benc)

So condstore (bug 1747311) and other imap issues should help more.

Depends on: 1747311
Severity: major → S3
No longer depends on: 1747311
See Also: → 1747311
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: