On Wed, Aug 2, 2017 at 7:44 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Wed, Aug 02, 2017 at 07:11:23PM +0200, Marco Pizzoli wrote: > > > Have a look at: > > - smtp_tls_session_cache_database <-- this is the most important thing. > I > > suggest lmdb as the backing store > > Yes, but Berkeley DB also works well enough in practice. > I believe you. But my experience comparing the two in OpenLDAP is strongly toward lmdb. > - if you are on Linux on virtual, also to RNGD/Haveged (the second being > > the best for speed) > > I don't think this is good advice. Use the default entropy source: > > tls_random_source = dev:/dev/urandom > > and let the kernel take care of entropy. > I did not say to change the default entropy source configured in postfix. I only meant to "help" the /dev/random source by making use of (one of) those daemons. In virtual machines the entropy is really low. In my vmware machines I am at 300, compared to the maximum possible of 4000. Those daemons really do help. During one of my bulk-sendings I saw the rngd daemon popping up within "top", so to say it needed to do its job. > > - loading jemalloc as the memory allocator for all postfix processes > > This is unlikely to be a bottleneck for SMTP. The default malloc should > be just fine. Could be, but jemalloc (and tcmalloc) give also benefit for memory fragmentation, apart for the pure allocation speed. So in constrained memory systems more than in those with huge memory they make you at least not-losing-something in the long term. Or at least they should. > The only real tuning required for a dedicated upstream > is: > > - Enable the client-side SMTP TLS session cache > Confirm > - Make sure the upstream server supports session resumption, ideally > via session tickets, but a remote cache is also ok. > Confirm. Indeed I don't see all of them supporting it, unfortunately. > - Increase concurrency as required for the larger TLS > round-trip delay. If the average message size is large > enough, the latency increase will be small, and perhaps no > tuning is required. If the average message size is small, > a multiple of 2 or a bit more may be appropriate. > On this latest point I have to *in part* disagree... My experience makes me doubtful on just extending the concurrent connections towards the remote systems. I actually need to limit the concurrent connection number to my destinations in order to not be deferred due to the "too many connections from your IP". > > -- > Viktor. >
