User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 Build Identifier: 3.1.8 We are using Thunderbird with the thin client environment, so our mailbox of Thunderbird are on the NFS server. In the case of the NFS mailbox environment, we are faced with a serious performance problem during every mail receiving. Could you please fix this performance problem? Environment: Client MAC OSX 10.6.5 Thunderbird 3.1.8 NFS server RHEL 5.5 Mail server RHEL 5.5 POP3 In the past, we used Thunderbird v2 (2.0.0.24) with same NFS mailbox environment and it took about 10 seconds for receiving the mail. According to the announcement of Thunderbird v2 withdrawal, we replaced Thunderbird v3, then we met the massive performance regression of mail receiving. It took over 3 hours for receiving the same volume of mails. It became more than 1000 times slowly. It gave us a long lunch break, but still doesn't finish. First, I thought the cause of the performance problem is our mail server and investigated the network packets between Client and Mail server. But it seems the Mail server works smoothly and the Client works slowly, so I think our mail server doesn't have any problem. Next, I investigated the network packets between Client and NFS server. I found there were a huge number of packets of write()/seek() combinations. According to the results of system trace, each write() process of about 80 bytes had single seek() with SEEK_END option and it happened over 100 times per one second. It seems it's too heavy process for NFS mailbox. Follows are the results of strace; Local mailbox case: write() 32 microsec fstat() 36 microsec lseek() 26 microsec NFS mailbox case: write() 29 microsec fstat() 10942 microsec lseek() 26 microsec I think fstat() gets the size of the mailbox for SEEK_END. It seems that SEEK_END must pay high cost for NFS mailbox. The following source code of Thunderbird processes this write()/seek(). ===== start here ===== nsresult nsPop3Sink::WriteLineToMailbox(const char *buffer) { if (buffer) { PRInt32 bufferLen = PL_strlen(buffer); if (m_newMailParser) // HandleLine should really take a const char *... m_newMailParser->HandleLine((char *) buffer, bufferLen); // The following (!m_outFileStream etc) was added to make sure that we don't write somewhere // where for some reason or another we can't write to and lose the messages // See bug 62480 if (!m_outFileStream) return NS_ERROR_OUT_OF_MEMORY; // seek to the end in case someone else has seeked elsewhere in our stream. nsCOMPtr <nsISeekableStream> seekableOutStream = do_QueryInterface (m_outFileStream); seekableOutStream->Seek(nsISeekableStream::NS_SEEK_END, 0); PRUint32 bytesWritten; m_outFileStream->Write(buffer, bufferLen, &bytesWritten); if ((PRInt32) bytesWritten != bufferLen) return NS_ERROR_FAILURE; } return NS_OK; } ===== end here ===== The source codes say the reason why SEEK END happend is "seek to the end in case someone else has seeked elsewhere in our stream.". But it's too much. For example, I propose the following fix codes to avoid wasted SEEK ENDs. It just one example, but the following code resolves this performance problem of NFS mailbox completely. However, I'm not sure if it is correct. Could you please fix the performance problem of Thunderbird v3? ===== start here ===== diff -r 3967c525ac7e mailnews/base/util/nsMsgFileStream.h --- a/mailnews/base/util/nsMsgFileStream.h Sun Jan 23 09:24:48 2011 -0800 +++ b/mailnews/base/util/nsMsgFileStream.h Fri Feb 04 00:24:36 2011 +0900 @@ -21,5 +21,6 @@ nsresult InitWithFile(nsILocalFile *localFile); protected: PRFileDesc *mFileDesc; + PRBool mSeekEnd; }; diff -r 3967c525ac7e mailnews/base/util/nsMsgFileStream.cpp --- a/mailnews/base/util/nsMsgFileStream.cpp Sun Jan 23 09:24:48 2011 -0800 +++ b/mailnews/base/util/nsMsgFileStream.cpp Fri Feb 04 00:24:36 2011 +0900 @@ -31,6 +31,7 @@ nsMsgFileStream::nsMsgFileStream() { mFileDesc = nsnull; + mSeekEnd = PR_FALSE; } nsMsgFileStream::~nsMsgFileStream() @@ -51,11 +52,17 @@ { if (mFileDesc == nsnull) return NS_BASE_STREAM_CLOSED; + + PRBool seekend = (PRSeekWhence)whence == PR_SEEK_END && offset == 0 ? PR_TRUE : PR_FALSE; + if (seekend == PR_TRUE && mSeekEnd == PR_TRUE) + return NS_OK; nsInt64 cnt = PR_Seek64(mFileDesc, offset, (PRSeekWhence)whence); if (cnt == nsInt64(-1)) { return ErrorAccordingToNSPR(); } + mSeekEnd = seekend; + return NS_OK; } ===== end here ===== Reproducible: Always Steps to Reproduce: 1. Mount NFS file system on your PC. 2. Place your mailbox on the NFS directory. 3. Run Theunderbird v3 and receive your mail from pop3. Actual Results: For recieving 958 mails (35MB), it took over 3 hours. However, in the case of Thnderbird v2, it took about 10 seconds. Expected Results: I expect it is on the order of a few second for receiving mail.

Ogino-san, would you recreate the patch on comm-central and make a diff file with -U 8 -p and attach it to this bug. Finally, request review to dbienvenu@mozilla.com?

Thx for looking at this - if you're going to generate a new patch, I would change the name of mSeekEnd to be mSeekedToEnd, since it's keep track of whether we've already seeked to the end. and this can simply be: PRBool seekingToEnd = whence == PR_SEEK_END && offset == 0;

Thx for the new patch; I've tweaked it a little and this is the patch I plan to check in.

(In reply to comment #4) > Created attachment 527170 [details] [diff] [review] > patch for checkin > > Thx for the new patch; I've tweaked it a little and this is the patch I plan to > check in. David are we just waiting for a green tree ?

fixed on trunk, thx for the patch http://hg.mozilla.org/comm-central/rev/c673f486cb43