[
https://issues.apache.org/jira/browse/JAMES-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3485:
----------------------------------
Attachment: Screenshot from 2020-12-25 19-54-22.png
Screenshot from 2020-12-25 19-54-30.png
Screenshot from 2020-12-25 19-54-38.png
> JMAP: Sending a message read reads too much data in Cassandra
> -------------------------------------------------------------
>
> Key: JAMES-3485
> URL: https://issues.apache.org/jira/browse/JAMES-3485
> Project: James Server
> Issue Type: Improvement
> Reporter: Benoit Tellier
> Priority: Major
> Attachments: Screenshot from 2020-12-25 19-54-22.png, Screenshot from
> 2020-12-25 19-54-30.png, Screenshot from 2020-12-25 19-54-38.png
>
>
> Reading glowroot, I notice sending messages triggers many Cassandra requests.
> See attached screenshots:
> - [1] should overall requests. We can spot a very high number of mailboxes
> reads, acl reads, and message reads. The analysis of the traces entries shows
> that:
> - [2] attachment validation leads to many reads. For each attachment, 7
> Cassandra reads is performed (checking both if the attachment had been
> uploaded or belongs to a message the user can read). Interestingly enough, a
> code analysis shows that:
> - messagev3 reads are uneeded upon attachment checks
> - AttachmentManager already expose grouped reads for attachments, but
> this API is not leveraged for perfomance enhancements.
> - [3] the request ends up mostly reading ACLs.
> This is linked to a full account search to retrieve the message that had been
> answered/forwarded. By retrieving mailboxes - and thus acls, we perform many
> unneeded reads.
> We expect a sharp drop in request count by:
> - Avoiding reading messagev3 table upon attachment right checks.
> - Grouping right validation for attachment at always attachments belongs to
> the same draft message.
> - Reworking all mailbox search to less read ACLs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
