james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger <jdrae...@gmx.de>
Subject Re: [jira] Commented: (JAMES-720) STATUS command performance
Date Tue, 05 Dec 2006 13:11:20 GMT
Am Montag, den 04.12.2006, 14:42 -0800 schrieb Robert Burrell Donkin 

> My local fork has wandered quite a way away from the JAMES base: I gave up running the
test suite on my personal fork quite a while ago. The code wasn't really intended to be a
serious proposal. just what works for me. 

So what are the most itching issues you have fixed in your local branch
that aren't in trunk? Maybe we can bring them a bit nearer.
Apart from that you could check out a second instance of trunk to be
uptodate with recent changes. This way you could try out and test your
ideas with valid results.

> The STATUS issue is so large when using evolution that it renders JAMES IMAP unusable
for anyone other than developers. it basically takes 10 minutes to open the client even with
the relatively small volumes of data I have currently (probably < 5000 messages).
> Any speed up would be great but i fear that something more radical may be needed. Evolution
sends a STATUS every couple of minutes for every visible mailbox.  

In fact the current intended audience are only developers because it is

Did you try out the recent changes I made to TorqueMailbox? 
IMO this should solve the worst problems. Opening a session with 1000
messages took about 1000 ms. Okay that is also quite slow.
The join logic inside Torque is not well optimized. 
(It uses a nested loop instead of a HashSet which causes n(n+1)/2
I reimplemented the join logic and opening of 10000 messages needs about
1000 ms now.

> If the hack above sounds risky then perhaps it would be wise to consider altering the
MailboxManager API. Perhaps pass through a parameter object (MailboxConfiguration, say) with
mailboxName as a property something like:
> public interface MailboxManager {
>     ...    
>     ImapMailboxSession getImapMailboxSession(MailboxConfiguration configuration) throws
>     ...
> }
> Then a 'readOnly' property could be added to the configuration object. Given that the
mailbox is not used for writing then it should be safe enough to postpone loading the cache
until needed. STATUS command (and any other similar ones that happen to have performance issue)
could set this property to true. This would isolate the potential impact of not caching on

Opening a session readonly could be an enhancement for the future but I don't think that it's
the solution for this problem.
It would also be possible to put getNumberCache() at the top of all needed methods of the
I prefer reviewing the whole number cache thing and running tests before making any decisions
concerning changes to the API. 
At the moment I consider 1000 ms for 10000 messages as reasonable.

Which similar ones have you got in mind?


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message