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/06/23 07:09:00 UTC

[jira] [Created] (JAMES-3265) Investigate Slow IMAP SELECT (26 minutes +)

Benoit Tellier created JAMES-3265:
-------------------------------------

             Summary: 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
             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