Thunderbird stores all data in the profile folders see https://support.mozilla.org/en-US/kb/profiles-tb#w_where-is-my-profile-stored

Thunderbird default action is to store local copies of mail for IMAP accounts.

More common causes of slow update are bad add-ons and external programs (usually anti virus)/

Standard diagnostics are

• Restart Thunderbird with add-ons disabled (Thunderbird Safe Mode). On the Help menu, click on "Restart with Add-ons Disabled". If Thunderbird works like normal, there is an Add-on or Theme interfering with normal operations. You will need to re-enable add-ons one at a time until you locate the offender.
• Restart the operating system in safe mode with Networking. This loads only the very basics needed to start your computer while enabling an Internet connection. Click on your operating system for instructions on how to start in safe mode: Windows 8, Windows 7, Windows Vista, Windows XP, OSX

If safe mode for the operating system fixes the issue, there's other software in your computer that's causing problems. Possibilities include but not limited to: AV scanning, virus/malware, background downloads such as program updates.

Matt said

Thunderbird stores all data in the profile folders see https://support.mozilla.org/en-US/kb/profiles-tb#w_where-is-my-profile-stored Thunderbird default action is to store local copies of mail for IMAP accounts. ...

This may be the problem. The user's profile is stored on the IMAP server, not on the local computer. So, if the inbox folders are set to keep "local copies" would I just be making the problem worse by storing both actual IMAP message files and Thunderbird "local copies" remotely? I notice the that TB ImapMail files are .msf's. Are these more compact or efficient for TB to search and maybe this actually helps speed things up?

Is there a way to put local-copy folders elsewhere other than under the profile folder?

This workstation's Thunderbird has the Lightning "extension", but there are no add-ons installed , and no plug-ins activated. We can't kill our AV program (VIPRE), but all users have VIPRE and not all users experience this problem. My feeling is that it is related to total messages and folders -- users with few messages have no typing latency issues.

Before you ask why the user's profile is stored on the server ... this WIN7 workstation is part of a Windows AD domain. The "server" is the AD/DC domain controller, and IMAP mail server, and holds the Windows "Redirected Folders" (i.e. user's Desktops, Documents, etc.). The workstation can dual-boot Windows and Ubuntu and, with Thunderbird on both, the same profile needs to be accessible by both. Since this is an AD environment, users can log on to any workstation in the office (Windows or Ubuntu) and see their same desktop, documents, etc ... and need to access their same TB profile.

All this does work, just some users are experiencing typing latency when composing messages.

At the moment I've enabled "local copying" of this user's inbox folders. I'll let this run a day or so to see if that helps. I'm hoping that even though the local copies are still on the server, the 30-day subsetting and .msf format might speed things up -- we'll see.

Meanwhile, if there's a way to really put the local copies on the local computer ... ?

YOu know there is a reason remote profiles exist in Windows. It increases logon-log-off times. but it does leave for a much better user experience.

However are their local copies to the profile at all? If the user profile IMAP mail folder only contains MSF files, it would be that the user account in Thunderbird is set to only retrieve headers If there were local copies there would be an MSF file and index and say inbox.msf. accompanied by an inbox. file which actually contains the mail data. It's absence says no local copies.

So your left with a cache, which might be full. or a problematical network connection. Given the loads your placing on your server making it an applications server really just how busy is it? Is there any issue with the network other than Thunderbird on those machines.

I would try the cache first as your seeing a correlation of profile size to those with issues. Given no local copies of the profile the cache will probably be getting a real workout.

On the toolbar > options> advanced>Network and Disk Space> Clear the cache and see if tht helps. I think it might make it worse in the very short term as everything required is fetched from the server.

Then look at increasing the size. I give mine 1GB, I have loads of free disk space and really just have no interest in fiddling with the cache. But anything less that 3 or 4 hundred MB is probably going to cause issues. in your environment. But what works for you I have no idea as your storing the local cache remotely on a server. Interesting conundrum that presents hey.

While you can not kill Vipre, you might look at excluding the Thunderbird profile folder from any sort of on access scanning. You might also look at a file exclusion for nsmail.html in the users temp folder. It has caused issues in the past with other anti virus programs. It is used briefly to assemble the email after the user clicks send.

Matt said

[deleted] However are their local copies to the profile at all? If the user profile IMAP mail folder only contains MSF files, it would be that the user account in Thunderbird is set to only retrieve headers If there were local copies there would be an MSF file and index and say inbox.msf. accompanied by an inbox. file which actually contains the mail data. It's absence says no local copies.

Yes, in the remote profile folder: \\mail.hprs.local\Users\<thisuser>\.thunderbird\ImapMail\<thisdomain> there are both INBOX and INBOX.msf files, the msf file having been last updated today shortly after midnight, the INBOX file being update 2 hours ago (19:26). So, "local copies, yes?

So your left with a cache, which might be full. or a problematical network connection. Given the loads your placing on your server making it an applications server really just how busy is it? Is there any issue with the network other than Thunderbird on those machines.

Thankfully, the server is Linux and Samba4, not Microsoft SBS or Server 20xx. In addition to the mail and AD functions, this server also continuously mounts all workstation C: drives and does a comparative scan of all files (looking for newly downloaded malware); but despite everything it's doing, the CPU remains between 97% and 100% idle. No known problems with network throughput - the server is local and it and all workstations have a wired gigabit connection. However to double-check, I will run iftop during business hours tomorrow.

I would try the cache first as your seeing a correlation of profile size to those with issues. Given no local copies of the profile the cache will probably be getting a real workout. On the toolbar > options> advanced>Network and Disk Space> Clear the cache and see if tht helps. I think it might make it worse in the very short term as everything required is fetched from the server. Then look at increasing the size. I give mine 1GB, I have loads of free disk space and really just have no interest in fiddling with the cache. But anything less that 3 or 4 hundred MB is probably going to cause issues. in your environment. But what works for you I have no idea as your storing the local cache remotely on a server. Interesting conundrum that presents hey.

OK, I've cleared the cache and bumped it from the default of 350M to 1G. I also turned off the "Compact all folders ..." setting. I've only used 5% of available disk space on the server so compacting is not needful, plus I have to believe that un-compacting when accessed takes time.

While you can not kill Vipre, you might look at excluding the Thunderbird profile folder from any sort of on access scanning. You might also look at a file exclusion for nsmail.html in the users temp folder. It has caused issues in the past with other anti virus programs. It is used briefly to assemble the email after the user clicks send.

Good thought. The profile folder is not on a local drive and Vipre does not scan network drives. I did add C:\temp\nsmail.html to the "Allow" list. I also unchecked "Enable Email Protection". My email choices are Outlook, Outlook Express and Other (e.g. Thunderbird). Outlook was previously checked. I don't think I need this because viruses are checked on the mail server. I'll probably revisit this later as Vipre is probably better than clamav.

I'll report back with user-results. FYI - I did turn on that Synchronization of the inbox folders yesterday, as discussed previously and, according to the user, performance was very acceptable today. Caching the last 30 days in a quicker-to-access format, even though still on the server, may have done the trick.

You appear to be mixing metaphors with compact and compress.

Compact is a purge if mail marked as deleted through deletions and moves to new folders. Some disk space is recovered, but the principal of the process is so we don't have 4Gb of deleted mail lurking in folders that to the user appears to have 5 mails that should occupy no more that 1mb.

There is certainly no overhead from uncompacting. as this is not something that can be undone. If your familiar with IMAP terminology, compact is very similar to Expunge.

Matt said

You appear to be mixing metaphors with compact and compress.

Ah! Yes, I'm certainly mixing "compact" and "compress" in this case. Before I turn that back on ... what is it compacting? If the caches files, fine, but I don't want Tbird to purged messages marked as deleted in the server's actual IMAP message file repository. These users keep their deleted messages for years -- not with my blessing.

Deleted messages are copied to the deleted folder and marked as deleted in the store file. these hidden deleted messages build up over time and need to be removed, if for nothing else but to keep the file size manageable. That is compacting.

Thanks Matt, but I don't understand whether that answers my question. Are you talking about deleted message in the IMAP server's deleted mail folder, or are you talking about deleted messages in the "local copies" cache?

the moved mail is in the servers deleted mail folder. The deleted mail that is compacted are orphan copies left in say the inbox folder by the delete action.

Thanks, also this link answers the question: https://support.mozilla.org/en-US/kb/compacting-folders, it is "compacting" the "local copy" cached messages which are stored in mbox format, and the index is recreated. Compacting is automatically done when doing so would save 20+MB. So, I'll turn compacting on.

Meanwhile, the user reports no type-ahead delay issues, so the combination of caching the inbox and increasing the cache size appears to have done the trick, even though the cache is itself on the server. Now I'll work on my calendar issues!

Thanks.