On Wed, Aug 2, 2017 at 6:57 PM, mark burdett <mfburd...@gmail.com> wrote:
> That's true, as a work-around. Unfortunately we're talking about not just > opening a new TCP connection but also reestablishing TLS, which means yet > more RTT and CPU. So the increased concurrency will be significant and > will require upping limits on the client and server side. I'm guessing > most folks in this scenario will prefer to code a lightweight SMTP worker > that can reuse connections, running at a lower concurrency. > > --mark B. > Don't take for granted that you can't optimize things. I have an important experience to share... I faced the same issue when enabling the SSL connection to the remote systems. My 220K email sending was lasting 2/3 hours more than without SSL. Now I can send 100K emails in 1h, with a single Postfix instance and a single sending IP address. On a virtual Linux machine on VMware. Have a look at: - smtp_tls_session_cache_database <-- this is the most important thing. I suggest lmdb as the backing store - if you are on Linux on virtual, also to RNGD/Haveged (the second being the best for speed) - making use of the most recent openssl major version you can afford to link postifx to - loading jemalloc as the memory allocator for all postfix processes Provided that the hard drive won't be an issue, you will see a considerable difference in the performance.
