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 2022/05/05 04:57:00 UTC
[jira] [Commented] (JAMES-3086) Mail Server Load Test giving very low throughput
[ https://issues.apache.org/jira/browse/JAMES-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532065#comment-17532065 ]
Benoit Tellier commented on JAMES-3086:
---------------------------------------
Hello, I am getting a fresh look at this:
- elastic threads are not related to elasticsearch but is the kind of thread we use in reactor (our reactive library) to handle potentially blocking taks
- Those elastic threads sits there doing nothing. Waiting...
- Use of elastic is deprecate because it just starts too many threads, reactor community prefer using bounded elastic. Such a move should be done in James too. A SEDA architecture can be used to prevent deadlocks.
- As Cassandra 3.x is not fully reactive, paging can block. We thus aggressively switch threads to avoid blocking in parralel threads. A migration to a true reactive driver (4.x) would allow us to solve this, dramatically reducing the count of allocated elastic threads. This would also decrease scheduling overhead, context switches...
- Busy threads are the SMTP threads as well as the spooler threads (mail processing) which essentially blocks. This would benefit from a migration to pure reactive code just like we did for the IMAP protocol. I would be happy to get sponsored doing this!
I suggest you use https://github.com/jvm-profiling-tools/async-profiler when reporting "over exhausted CPU", its flame graphs allows knowing exactly what the CPUs are doing which is invaluable. This is further more a really easy to use tool.
> Mail Server Load Test giving very low throughput
> ------------------------------------------------
>
> Key: JAMES-3086
> URL: https://issues.apache.org/jira/browse/JAMES-3086
> Project: James Server
> Issue Type: Bug
> Components: POP3Server, SMTPServer
> Affects Versions: 3.3.0
> Reporter: Rashid Mahmood
> Priority: Blocker
> Attachments: executors-waiting-to-acquire.png, image-2020-03-04-09-30-30-054.png, threaddump.txt
>
>
> After functional tests, we are performing load tests against James Server setup with Casandra/Elasticsearch(cassandra-ldap-guice) packaging option. With JMeter constant throughput timer of 300 SMPT requests per seconds we are achieving around 10 requests per seconds. Each Request is with 100KB attachment. Observed CPU of the machine (where MailServer running) was over exhausted.
> Many of the threads in thread dump were in awaiting notifications state.
> I see around 100 threads from Elastic search, is there any configuration to control this?
> Where is the bottleneck?
> !image-2020-03-04-09-30-30-054.png!
>
> See the thread dump in attachment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org