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 "Benoit Tellier (Jira)" <se...@james.apache.org> on 2020/07/07 10:16:00 UTC
[jira] [Commented] (JAMES-3265) Investigate Slow IMAP SELECT (26
minutes +)
[ https://issues.apache.org/jira/browse/JAMES-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152620#comment-17152620 ]
Benoit Tellier commented on JAMES-3265:
---------------------------------------
Here is a report about my activities today at optimizing IMAP speed on a production system on top^of Distributed James.
Some enhencements cary over out of the box to other james server distribution, some others could be adapted to other mailbox backends to leverage better performances, some others target some specific mailbox/cassandra puitfall.
Here is the the list:
- https://github.com/linagora/james-project/pull/3556 JAMES-3265 Optimize COPY & MOVE
- https://github.com/linagora/james-project/pull/3555 JAMES-3265 Fasten fetching all flags
- https://github.com/linagora/james-project/pull/3554 JAMES-3265 Flags updates should not infinite loop on denormalization
> Investigate Slow IMAP SELECT (26 minutes +)
> -------------------------------------------
>
> Key: JAMES-3265
> URL: https://issues.apache.org/jira/browse/JAMES-3265
> Project: James Server
> Issue Type: Task
> Components: cassandra, IMAPServer
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Labels: perf
> Fix For: 3.6.0
>
> Attachments: Capture_d_écran_de_2020-06-22_11-42-01.png, Capture_d_écran_de_2020-06-22_11-48-28.png
>
>
> Using glowroot APM on Linagora run instances, I noticed some select commands takes around 20 minutes.
> A performance review shows thousands of MODSEQ updates undermines the performance.
> {code:java}
> Transaction type: IMAP
> Transaction name: IMAP processor : org.apache.james.imap.processor.SelectProcessor
> Start: 2020-06-22 2:28:04.433 am (+07:00)
> Duration: 1,618,718.3 milliseconds
> {code}
> I noticed a high allocation of new ModSeq (28.000 instead of 1) due to uid set disjonction.
> I believe a solution would be to implement a new MessageMapper method:
> Mono<Void> removeRecentFlags(Mailbox mbox);
> That would enable some Cassandra query optimizations...
> # DOD
> - unlock significant performance improvments for such queries (x100)
> Attached you will find the query stats and flame graph backing up the analysis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org