[
https://issues.apache.org/jira/browse/JAMES-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3263:
----------------------------------
Description:
Doing a slowtrace analysis for the webAdmin protocol on one of Linagora
deployments:
{code:java}
Transaction type: Web
Transaction name: GET /address/aliases/address/aliases
Start: 2020-06-23 8:03:41.284 am (+07:00)
Duration: 9,639.2 milliseconds
Request http method: GET
Response code: 200
{code}
Listing all mappings, a common operation is slow.
Surprisingly, query executes really fast at the Cassandra levels, and some
other processing seems to be taking time:
Capture_d_écran_de_2020-06-23_09-21-12.png demonstrate query timings and we can
see Cassandra query takes less than 200 ms and the time is spent elsewhere.
Looking at the code, collection processing does a lot of immutable copies
(MappingsImpl::build calls.
Better rewritting the reduce operation would certainly unlock a performance
improvment.
The glowroot flame graph seems to correlate with this analysis (disclaimer: I
had a look at it after doing this analysis)
Capture d’écran de 2020-06-23 09-24-17.png shows 9 traces out of 10 relating to
the above mentionned collect
**Definition of done**
x100 improvment for large collections on top of memory backend for local
benchmarks
was:
Doing a slowtrace analysis for the webAdmin protocol on one of Linagora
deployments:
{code:java}
Transaction type: Web
Transaction name: GET /address/aliases/address/aliases
Start: 2020-06-23 8:03:41.284 am (+07:00)
Duration: 9,639.2 milliseconds
Request http method: GET
Response code: 200
{code}
Listing all mappings, a common operation is slow.
Surprisingly, query executes really fast at the Cassandra levels, and some
other processing seems to be taking time:
Capture_d_écran_de_2020-06-23_09-21-12.png demonstrate query timings and we can
see Cassandra query takes less than 200 ms and the time is spent elsewhere.
Looking at the code, collection processing does a lot of immutable copies
(MappingsImpl::build calls.
Better rewritting the reduce operation would certainly unlock a performance
improvment.
The glowroot flame graph seems to correlate with this analysis (disclaimer: I
had a look at it after doing this analysis)
> GET /address/aliases/address/aliases is slow (9s +)
> ---------------------------------------------------
>
> Key: JAMES-3263
> URL: https://issues.apache.org/jira/browse/JAMES-3263
> Project: James Server
> Issue Type: Task
> Reporter: Benoit Tellier
> Priority: Major
> Attachments: Capture d’écran de 2020-06-23 09-24-17.png,
> Capture_d_écran_de_2020-06-23_09-21-12.png
>
>
> Doing a slowtrace analysis for the webAdmin protocol on one of Linagora
> deployments:
> {code:java}
> Transaction type: Web
> Transaction name: GET /address/aliases/address/aliases
> Start: 2020-06-23 8:03:41.284 am (+07:00)
> Duration: 9,639.2 milliseconds
> Request http method: GET
> Response code: 200
> {code}
> Listing all mappings, a common operation is slow.
> Surprisingly, query executes really fast at the Cassandra levels, and some
> other processing seems to be taking time:
> Capture_d_écran_de_2020-06-23_09-21-12.png demonstrate query timings and we
> can see Cassandra query takes less than 200 ms and the time is spent
> elsewhere.
> Looking at the code, collection processing does a lot of immutable copies
> (MappingsImpl::build calls.
> Better rewritting the reduce operation would certainly unlock a performance
> improvment.
> The glowroot flame graph seems to correlate with this analysis (disclaimer: I
> had a look at it after doing this analysis)
> Capture d’écran de 2020-06-23 09-24-17.png shows 9 traces out of 10 relating
> to the above mentionned collect
> **Definition of done**
> x100 improvment for large collections on top of memory backend for local
> benchmarks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
