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
> 


Reply via email to