[
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 init().
> 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 supported.)
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
