[ https://issues.apache.org/jira/browse/JAMES-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthieu Baechler reopened JAMES-3265: -------------------------------------- It may not be 26 minutes long but it's still slow and refactoring are probably needed for some quick-and-dirty fixes that happened today. > 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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org