Sjon wrote:
I have been trying to optimize RoundCube performance as well; but it is kind of difficult. RoundCube has multiple caches (both php-memory as mysql based) and it isn't always clear where data is coming from.
I think performance can be improved in the _list_headers function. This function requires all headers in a folder to be cached; before this cache will actually be used. This means that if the last of 400 pages has never been visited; RoundCube will never use it's cache of the other 399 pages. I have been trying to improve that; but unfortunately couldn't get it working properly. Viewing a 7000-items folder therefore remains to take 26 seconds to load on my machine.
That's not 100% correct: As long as the cache is not complete, RC has to fetch the *message index* from the server, which should not take too much time. The messages headers are retrieved from the local cache if available. This is done within the method _fetch_headers()
By the way, I just found a performance wasting line which shouldn't be there: you can remove line 564 from rcube_imap.inc ($a_header_index = iil_C_FetchHeaders....) because it just fetches headers for nothing. Must be still there from my experiments when I rewrote the caching functions.
Sorry for that! Thomas
If you would like to check the performance of certain RoundCube actions; insert the following code in your index.php file:
[...]
This will insert a timer for both webpages and javascript files.
Regards, Sjon
Thomas Bruederli wrote:
Mark Edwards wrote:
On Feb 24, 2006, at 1:35 PM, phil wrote: [snip]
Well, in any case, why is doing anything other than saying, "give me this particular message data" and then displaying it?
I guess that the cause of this problem is when RC fetches the message index to show the correct links to next/previous message. This is also done while opening a message and could be related to the mailbox size.
Just to locate the problem, you should remove/comment the lines 68 to 74 in program/steps/mail/show.inc and check if performance is getting better.
I don't have an idea what takes that long in fetching the message index (just doing a SORT command and then fetching the UIDs)
Any suggestions to improve this operation are welcome.
Regards, Thomas