Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-3506

SMTP stack is slow and generate high GC when under high traffic

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 3.6.0
    • Blob, mailbox, SMTPServer
    • None

    Description

      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.

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            btellier Benoit Tellier
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 1h
                1h

                Slack

                  Issue deployment