james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-720) STATUS command performance
Date Mon, 04 Dec 2006 22:42:23 GMT
    [ http://issues.apache.org/jira/browse/JAMES-720?page=comments#action_12455439 ] 
Robert Burrell Donkin commented on JAMES-720:

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. 

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.  

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 MailboxManagerException;

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

> STATUS command performance
> --------------------------
>                 Key: JAMES-720
>                 URL: http://issues.apache.org/jira/browse/JAMES-720
>             Project: James
>          Issue Type: Improvement
>          Components: IMAPServer
>    Affects Versions: Trunk
>         Environment: evolution email client 
>            Reporter: Robert Burrell Donkin
>         Assigned To: Joachim Draeger
>         Attachments: STATUS-perf.patch
> I've been running my server for a little while with extra performance logging to try
to work out why it's sluggish. 
> The command parsing is orders of magnitudes faster than the data access. 
> The reasons seems to be the performance of the STATUS command. Since STATUS is typically
called every couple of minutes for every mail box visible on screen, it's quite a significant
issue for this email client. (some other clients use SEARCH instead but this is no currently
> This performance seems to worsen quickly as the number of messages in the box increases.
> On my box:
> STATUS on an empty mailbox with three empty sub mailboxes takes ~45 ms
> STATUS on a mailbox with ~10 read messages takes ~100ms
> STATUS on a mailbox with ~ 50 messages with 40 unread takes ~450ms
> STATUS on a mailbox with ~ 150 with 40 unread takes ~1800ms
> STATUS on a mailbox with ~ 570 unread messages takes ~6600ms
> Any clues about where to start looking?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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

View raw message