[
https://issues.apache.org/jira/browse/JAMES-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Baechler reopened JAMES-3265:
--------------------------------------
It looks like you ignored my last comment: at least
https://github.com/linagora/james-project/pull/3555 requires a more subtle
solution to avoid API duplication.
I prefer to keep that ticket open to track the need for a better solution
> 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: [email protected]
For additional commands, e-mail: [email protected]
