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 2021/03/08 06:33:00 UTC
[jira] [Closed] (JAMES-3506) SMTP stack is slow and generate high
GC when under high traffic
[ https://issues.apache.org/jira/browse/JAMES-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Tellier closed JAMES-3506.
---------------------------------
Resolution: Fixed
> SMTP stack is slow and generate high GC when under high traffic
> ---------------------------------------------------------------
>
> Key: JAMES-3506
> URL: https://issues.apache.org/jira/browse/JAMES-3506
> Project: James Server
> Issue Type: Improvement
> Components: Blob, mailbox, SMTPServer
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.6.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We had been documenting that SMTP stack is slow and generate a lot of GC (https://github.com/apache/james-project/pull/309#issuecomment-786358253)
> Under the hood, in memory structures are being used by the distributed server (MailStore, for both enqueuing and dequeuing emails), copies are enforced by inefficient APIs (eg InputStream) that prevents replaying the content (while we can!) and forces defensive copies.
> Out of this diagnosis, I started experimenting in https://github.com/apache/james-project/pull/309 trying to apply the following principles on the SMTP write path:
> - Avoid holding in memory data structures
> - Avoid copies by allowing stream generation
> My work show that I achieved a x3 SMTP throughput improvement. All dbs, including a zenko S3 server, being hosted on the same server of my test infra, I expect the gains to be even higher for real deployments.
> This work on efficiency should largely outweight the performance impacts of JAMES-3477.
> I would wish this work makes it to the future 3.6.0 release.
> On the upcoming topics of attention in my head that might see related works is the APPEND command buggy inMemorySize limits (exceeding the size limit causes the APPEND to crash), thus as a temporary remediation we did enforce a higher memory limit, hence defeating the above mentioned principles. I would prefer seeing there a FileBackedOutputStream with a replayable byte source, achieving similar enhencements for the APPEND command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org