[
https://issues.apache.org/jira/browse/JAMES-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207916#comment-17207916
]
Benoit Tellier commented on JAMES-3403:
---------------------------------------
No not really.
https://github.com/linagora/james-project/pull/3862 reverts changes within the
UidMSN converter but don't affect it's external behaviour.
I do not want revert the all work about JAMES-3177 but only this very commit.
Here is a micro-benchmark I did:
{code:java}
@Test
public void test() {
int endExclusive = 2000;
testee.addAll(IntStream.range(0, endExclusive)
.mapToObj(i -> MessageUid.of(i + 1))
.collect(Collectors.toList()));
Stopwatch started = Stopwatch.createStarted();
for (int i = 0; i < endExclusive; i++ ) {
testee.getMsn(MessageUid.of(i + 1));
}
System.out.println(started.elapsed(TimeUnit.MILLISECONDS));
}
{code}
Here are the results :
||Nb items||master||fix||
|1000|1175ms| 4 ms |
|2000|3971ms| 4 ms |
|4000|11739ms| 7 ms |
|10.000|Not finished| 42 ms |
|100.000|Not finished| 112 ms |
|1.000.000|Not finished| 526 ms |
By the way, I added a test to the proposed PR to better describe this revert.
Of course, this revert is an emergency measure, to get back a stable IMAP on
the master branch as quickly as possible. And if a kind contributor is willing
to invest some efforts to implement a performant, VAVR based version of
UidMsnConverter, that would be much appreciated ;-)
> 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: [email protected]
For additional commands, e-mail: [email protected]
