You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Joachim Draeger (JIRA)" <se...@james.apache.org> on 2006/12/02 18:17:22 UTC
[jira] Commented: (JAMES-720) STATUS command performance
[ http://issues.apache.org/jira/browse/JAMES-720?page=comments#action_12455106 ]
Joachim Draeger commented on JAMES-720:
---------------------------------------
Well, some backend operations are not optimized in any way.
And yes I don't consider parsing as significant.
But that case seems strange to me, because from a quick review I can say that
every information is retrieved by a single count() query. That should take only about 100ms even for 1000 messages!
Unfortunately torque doesn't support counting rows out-of-the-box at the moment,
Maybe this query does take long because it is misconstructed or indexes are missing.
Maybe there is an issue with derby.
At first we need to know where exactly the time is consumed.
You could instrument the code and put timemarks around the queries.
Just around all that mailbox.get*count() calls.
Is there a way to make derby log queries?
AFAIK Torque can be configured to log it's queries to log4j...
You could try out ImapServerLauncher. it is much easier to investigate such things when starting it from an IDE than starting whole James everytime.
SQuirreL SQL Client can be useful running statements on derby by hand.
> 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