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 Sun, 03 Dec 2006 20:37:23 GMT
    [ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message