[
https://issues.apache.org/jira/browse/JAMES-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208063#comment-17208063
]
Benoit Tellier commented on JAMES-3403:
---------------------------------------
For the record, Matthieu opened an alternative PR on top of existing VAVR code
here: https://github.com/linagora/james-project/pull/3865
Running the quick benchmark proposed above, it still takes (on my local
machine) 11459 ms, instead of 526ms for the revert (20x slower).
For people having large mailboxes this is likely a big deal.
Do we have opinions on that around here?
> IMAP Fetch: UidMSNConverter :: get MSN is slow
> ----------------------------------------------
>
> Key: JAMES-3403
> URL: https://issues.apache.org/jira/browse/JAMES-3403
> Project: James Server
> Issue Type: Bug
> Components: IMAPServer
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: master, 3.6.0
>
>
> # What?
> Following openpaas-1.7.15-rc2 deployment, and the use of VAVR immutable
> datastructures in UidMsnConverter, I notice some offending slow FETCH
> requests.
> A closer look shows Cassandra is not to blame here
> Flame graphs correlate the analysis
> On our prod set up 40k messages are enough to trigger endless FETCHs.
> # Why ?
> Fetch is calling getMSN(uid) one by one.
> Previous code was "getMSN optimized" as it uses an array as the underlying
> data structure. O(1) upon reads * n messages.
> The later code uses a red-black tree as an underlying data structure. I'm
> usure about the complexity here (because I am not a VAVR expert) but it is at
> least O(log n) * n messages.
> # Short term reaction
> Revert uneeded changes added in UidMsnConverter as part of work on JAMES-3177.
--
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
