Hi
On 25/07/2010 08:58, A.L.E.C wrote:
W dniu 2010-07-19 17:44, Ed W pisze:
The issue appears to be threading related - if I disable threading on the inbox then there is no delay on double clicking, only if I ask for the inbox to be threaded is there a delay opening an email
This seems to be confirmed by the log files from the mail server (Dovecot) which shows the imap requests on opening the message as follows:
thrd1 THREAD REFS US-ASCII ALL s SORT (ARRIVAL) US-ASCII ALL fuid FETCH 33027 (UID) fuid FETCH 32991 (UID) fuid FETCH 33006 (UID) fuid FETCH 6738 (UID)
We need this info to build page navigation (the arrows with links to first/previous/next/last message) and we need to call THREAD here, because we want to have the same messages order like in messages list. What IMAP server (and version) are you using? Which command (THREAD or SORT) takes longer? If SORT, you could try to change sorting to Date or None.
Possible solution would be to update navigation links in separate request after the page with a message is loaded.
Thanks for responding. The server is Dovecot (1.2.12)
What I think I didn't state clearly is that the IMAP stuff runs instantly and with no load on the server. However, then Roundcube code locks up for 45 secs with 100% CPU allocated to PHP before the page displays in the browser.
(For reference I have mysql, dovecot and php running on different (virtual) servers so it's quite easy to see where the load is. Further I use fastcgi with nginx so my php process is external and observable)
The log file showing the results of the imap commands above total 406KB, so some quick maths shows that we are getting back around the 33,000 results (that I mentioned matches the number of messages in my inbox) I haven't yet dug into the code, but it would seem very likely that something in the roundcube is trying to parse all of those results and choking?
I guess the question could be better rephrased as whether there is a more efficient way to retrieve (or at least parse) this information? Just glancing at the html produced it's not really clear why we would need all the data anyway? The navigation links don't appear to need this info? (Could you point to the code path perhaps so I can look closer?) The HTML *appears* to do a server side call to find the next/prev messages (so it seems like we retrieve this info only to print "message X of Y"?)
Grateful for any insights? To be clear I think this should be
reproducible for anyone else with a few thousand messages in a mailbox?
I don't think it's the imap server which is limiting performance, but
the PHP side?
Thanks
Ed W
List info: http://lists.roundcube.net/users/