[
http://issues.apache.org/jira/browse/JAMES-720?page=comments#action_12455207 ]
Robert Burrell Donkin commented on JAMES-720:
---------------------------------------------
I've found the cause of the problem. when a ImapMailboxSessionWrapper is
created, the init code is called in this superclass:
public abstract class NumberStableSessionWrapper extends AbstractGeneralMailbox
implements EventQueueingSessionMailbox,
MailboxListener {
...
public NumberStableSessionWrapper(GeneralMailbox generalMailbox) throws
MailboxManagerException {
setMailbox(generalMailbox);
init();
}
...
public void init() throws MailboxManagerException {
mailbox.addListener(eventDispatcher, MessageResult.UID);
getNumberCache();
eventDispatcher.addMailboxListener(this);
}
protected UidToMsnBidiMap getNumberCache() throws MailboxManagerException {
if (numberCache == null) {
MessageResult[] mr = mailbox.getMessages(GeneralMessageSetImpl
.all(), MessageResult.UID);
numberCache = new UidToMsnBidiMap();
for (int i = 0; i < mr.length; i++) {
numberCache.add(mr[i].getUid());
}
}
return numberCache;
}
as you can see, this calls getNumberCache.
This calls:
public class TorqueMailbox extends AbstractGeneralMailbox implements
ImapMailbox {
...
public MessageResult[] getMessages(GeneralMessageSet set, int result)
throws MailboxManagerException {
checkAccess();
if (!set.isValid()) {
return new MessageResult[0];
}
Criteria c = criteriaForMessageSet(set);
UidRange range = uidRangeForMessageSet(set);
try {
List l = getMailboxRow().getMessageRows(c);
MessageResult[] messageResults = fillMessageResult(l, result
| MessageResult.UID | MessageResult.FLAGS);
checkForScanGap(range.getFromUid());
getUidChangeTracker().found(range, messageResults, null);
return messageResults;
} catch (TorqueException e) {
throw new MailboxManagerException(e);
} catch (MessagingException e) {
throw new MailboxManagerException(e);
}
}
Nearly all the time is spent in this method.
Seems like a lot of time to spend when opening a sesson in any case (maybe lazy
caching would be a better plan) but it's a killer when requesting a STATUS.
> 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
>
> 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]
