Avatar for Username

Eheka Pytyvõha

Emboyke pytyvõha apovai. Ndorojeruremo’ãi ehenói térã eñe’ẽmondóvo pumbyrýpe ha emoherakuãvo marandu nemba’etéva. Emombe’u tembiapo imarãkuaáva ko “Marandu iñañáva” rupive.

Kuaave

Ko téma oñeñongatúma. Ejapo porandu pyahu eikotevẽramo pytyvõ.

How to speed up my Thunderbird?

  • 1 Mbohovái
  • 1 oguereko ko apañuái
  • 1 Hecha
  • Mbohovái ipaháva miketm

miketm
miketm
more options

Hello! We have been using ThunderBird for 12 years. Our team has about 15 people. Each person works with several IMAP folders. We have one folder (let’s call it “MAINFLD”) and a few additional ones. 12 years ago we were getting not more than 25 emails daily at the MAINFLD imap folder. Nowadays, emails are coming thick and fast (about 300 emails daily). So, nowadays, our ThunderBird works not as fast as 12 years ago. I mean it works really slowly! Periodically (usually once in 3 month) we cut our MAINFLD imap folder: emails for the previous 3 month go to the archive. It helps a little bit. I mean, right after archiving, ThunderBird works much faster, but after a while (when the quantity of emails in the imap folder reaches several thousands) it slows down again. It is not convenient for us to cut imap folder each month, because sometimes we need to find old emails. So, I decided to do an investigation. So, I ran ThunderBird with «set NSPR_LOG_MODULES=IMAP:5,timestamp» and when ThunderBird slows down, I were looking at the imap log and were trying to find some useful information there. So, I have found 3 interesting things mentioned below. Before we jump to the cases, I would like to say that I know about the recommendations mentioned here: http://kb.mozillazine.org/Performance_-_Thunderbird I have read them already and even followed a few recommendations from the list. I will recheck this list again soon. But here and now I would like to hear your comments about 3 cases I described below. 1. THE FIRST CASE The first one is about opening emails with a lot of images inside. At the moment of opening in the imap log I saw a numerous lines like this: 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: 14892800:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: IU2MTVNKaNdb6UQmGotfcOgCwVOs+1fXVtbWJsYmqERQei8Ui0wMDGMymiwWS+DK6Vxqo7gGrFGs 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: ReadNextLine [stream=1c9ca920 nb=78 needmore=0] 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: 14892800:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: QJJtFvL5qfExVdQG9OhLpJOkLqMwf9Y2Nnbt2nvvvY+QjO6amObajmJf4scppVwpV5hgQCDJNKrV 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: ReadNextLine [stream=1c9ca920 nb=78 needmore=0] So, as I understand, ThunderBird is reading the information about the images inside this email line-by-line. Each line is 78 bytes. The problem is that sometimes it takes about 4-5 seconds to open such an email. If you get a few emails a day is not a problem. But when emails are coming thick and fast it is really irritating to spend several seconds just for opening each of them. I do not know much about imap protocol. Is there any way to speed up this process: to increase the line length may be, or…? 2. THE SECOND CASE The second strange thing I found is: Sometimes, when I click on an email, ThunderBird slows down (even if an email itself does not have any heavy attachments, such as a lot of big sized pictures). At that moment in the status bar I see message something like “Trying to connect” or so (I use Russian language TB, the direct translation of the Russian message means that TB is making attempt to (re)connect). It may happen once in 2 minutes or sometime once in 5 minutes (I mean it happens not at every single click on the email, but periodically). During this slowness I see a lot of following messages in the imap log: 2018-09-19 10:24:31.953000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 I found a very similar bug 15 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=226989 But I do not know how to understand was it fixed somehow or not…May be it is even not the same problem. Does anybody know, is it possible to fix it somehow?

Hello! We have been using ThunderBird for 12 years. Our team has about 15 people. Each person works with several IMAP folders. We have one folder (let’s call it “MAINFLD”) and a few additional ones. 12 years ago we were getting not more than 25 emails daily at the MAINFLD imap folder. Nowadays, emails are coming thick and fast (about 300 emails daily). So, nowadays, our ThunderBird works not as fast as 12 years ago. I mean it works really slowly! Periodically (usually once in 3 month) we cut our MAINFLD imap folder: emails for the previous 3 month go to the archive. It helps a little bit. I mean, right after archiving, ThunderBird works much faster, but after a while (when the quantity of emails in the imap folder reaches several thousands) it slows down again. It is not convenient for us to cut imap folder each month, because sometimes we need to find old emails. So, I decided to do an investigation. So, I ran ThunderBird with «set NSPR_LOG_MODULES=IMAP:5,timestamp» and when ThunderBird slows down, I were looking at the imap log and were trying to find some useful information there. So, I have found 3 interesting things mentioned below. Before we jump to the cases, I would like to say that I know about the recommendations mentioned here: http://kb.mozillazine.org/Performance_-_Thunderbird I have read them already and even followed a few recommendations from the list. I will recheck this list again soon. But here and now I would like to hear your comments about 3 cases I described below. 1. THE FIRST CASE The first one is about opening emails with a lot of images inside. At the moment of opening in the imap log I saw a numerous lines like this: 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: 14892800:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: IU2MTVNKaNdb6UQmGotfcOgCwVOs+1fXVtbWJsYmqERQei8Ui0wMDGMymiwWS+DK6Vxqo7gGrFGs 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: ReadNextLine [stream=1c9ca920 nb=78 needmore=0] 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: 14892800:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: QJJtFvL5qfExVdQG9OhLpJOkLqMwf9Y2Nnbt2nvvvY+QjO6amObajmJf4scppVwpV5hgQCDJNKrV 2018-09-19 04:08:29.427000 UTC - 23112[29cedac0]: ReadNextLine [stream=1c9ca920 nb=78 needmore=0] So, as I understand, ThunderBird is reading the information about the images inside this email line-by-line. Each line is 78 bytes. The problem is that sometimes it takes about 4-5 seconds to open such an email. If you get a few emails a day is not a problem. But when emails are coming thick and fast it is really irritating to spend several seconds just for opening each of them. I do not know much about imap protocol. Is there any way to speed up this process: to increase the line length may be, or…? 2. THE SECOND CASE The second strange thing I found is: Sometimes, when I click on an email, ThunderBird slows down (even if an email itself does not have any heavy attachments, such as a lot of big sized pictures). At that moment in the status bar I see message something like “Trying to connect” or so (I use Russian language TB, the direct translation of the Russian message means that TB is making attempt to (re)connect). It may happen once in 2 minutes or sometime once in 5 minutes (I mean it happens not at every single click on the email, but periodically). During this slowness I see a lot of following messages in the imap log: 2018-09-19 10:24:31.953000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.984000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 2018-09-19 10:24:31.999000 UTC - 16960[e12140]: failed creating protocol instance to play queued url:imap://[email protected]:993/addmsgflags>UID>.quik.support.MAINFLD>1000284156>1 I found a very similar bug 15 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=226989 But I do not know how to understand was it fixed somehow or not…May be it is even not the same problem. Does anybody know, is it possible to fix it somehow?

Opaite Mbohovái (1)

miketm
miketm Porandu apoha
more options

3. THE THIRD CASE The third strange thing is: As I have already mentioned, we may have thousands emails in the imap folder. I found that ThunderBird periodically fetching flags. I see thousands of the following lines in the log: 2018-10-04 09:25:11.354000 UTC - 5104[c1b5f70]: 10963000:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: * 1 FETCH (FLAGS (7highat 3close $Forwarded) UID 1000255735) 2018-10-04 09:25:11.354000 UTC - 5104[c1b5f70]: 10963000:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: * 2 FETCH (FLAGS (\Answered 3close vskor) UID 1000255737) 2018-10-04 09:25:11.354000 UTC - 5104[c1b5f70]: 10963000:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: * 3 FETCH (FLAGS (3close) UID 1000255739) 2018-10-04 09:25:11.354000 UTC - 5104[c1b5f70]: 10963000:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: * 4 FETCH (FLAGS (3close) UID 1000255740) 2018-10-04 09:25:11.354000 UTC - 5104[c1b5f70]: 10963000:mail.domain.ru:S-quik.support.MAINFLD:CreateNewLineFromSocket: * 5 FETCH (FLAGS (3close) UID 1000255741) So, I understand why Thunderbird doing this. It is important to receive the current flags status to display the email correctly. Moreover, we use custom flags (tags), such as «vskor»,«3lcose», “7highat” (you may see them in the log fragment) and it is important for us to have actual status of these flags (tags). BUT, why does ThunderBird always get the statuses of ALL emails in the imap folder? I mean, If we have 30000 emails in the imap folder, Thunderbird gets 30000 lines from the imap server each time during flag synchronization. Is it possible to get flags only in case of change (particular flag at the particular email)? Is it a feature of imap protocol or imap server?We use «Cyrus imap server». Thank you!