On 27.07.2010 14:48, Ed W wrote:
So, slow is THREAD or its result parsing.
Yes, confirmed in the IMAP logs.
Yes what? The command or parsing?
So my reproducible behaviour is to take vanilla RC beta, connect to a
Better would be to use svn-trunk
dovecot instance with an inbox containing 33K messages, click the icon top left corner of the message list and choose "Thread" from the view options, very short pause while the list redraws, then finally double click on some small message
The imap logs from that point show the imap server very quickly (sub 1 second) return what appears to be the thread info for every message, then a sorted list of the same (sort states completed in 0.102 seconds) There is then a 45 sec (ish) delay before the connection resumes and
45 sec delay after SORT response? Please attach Roundcube's imap_debug log (with timestamps).
grabs the message itself and the browser suddenly wakes up and displays the message. During that period the PHP process is wedged at 100% cpu.
Then I go back into the message list, disable threading and this time double click on the same message. Now the message displays instantly. Comparing the imap_log I see what appears the exact same set of commands except for the lack of the threads list.
It would therefore seem extremely likely that it's the parsing of the imap THREAD results which is causing the delay and high CPU?
I cannot imagine a 45 sec delay just for PHP code. Please, attach complete THREAD command response.
Interesting that you don't see this? Does your 10K message folder contain any threaded messages? Do you have threading enabled in your message list view?
Yes, I have. Still I have no idea what it could be. Maybe it's something with parallel connections handling in dovecot? Check login_* options in dovecot.conf. When you open a message there are two requests, one for 'show' action and one for 'getunread'.