Re: possible bottlenecks

2020-10-17 Thread Peter Blair
At 17 October, 2020 Demi M. Obenour wrote: > > Postfix is not an HTTP server handling tens to hundreds of thousands of > > requests > > per second, and does not benefit from the optimisations needed for those > > kinds > > of workloads. Premature optimisations that sacrifice robustness and >

Re: possible bottlenecks

2020-10-17 Thread Viktor Dukhovni
On Sat, Oct 17, 2020 at 02:05:57PM -0400, Demi M. Obenour wrote: > > Postfix 3.4 and later grudgingly do some event-driven work because > > TLS connection reuse with OpenSSL is not possible out-of-process. > > So the tlsproxy(8) process context switches between multiple TLS > > connections, but th

Re: possible bottlenecks

2020-10-17 Thread Demi M. Obenour
On 10/17/20 1:23 AM, Viktor Dukhovni wrote: >> On Oct 17, 2020, at 3:09 AM, Demi M. Obenour wrote: >> >>> The practical limit to the deferred queue size is therefore ~2 days of >>> throughput, and depends heavily on the per-delivery latency. If >>> delivery failures are slow (tarpitting or otherw

Re: possible bottlenecks

2020-10-16 Thread Viktor Dukhovni
> On Oct 17, 2020, at 3:09 AM, Demi M. Obenour wrote: > >> The practical limit to the deferred queue size is therefore ~2 days of >> throughput, and depends heavily on the per-delivery latency. If >> delivery failures are slow (tarpitting or otherwise slow destinations) >> the impact is greater.

Re: possible bottlenecks

2020-10-16 Thread Demi M. Obenour
On 10/16/20 9:24 PM, Viktor Dukhovni wrote: > The practical limit to the deferred queue size is therefore ~2 days of > throughput, and depends heavily on the per-delivery latency. If > delivery failures are slow (tarpitting or otherwise slow destinations) > the impact is greater. Can the latency

Re: possible bottlenecks

2020-10-16 Thread Viktor Dukhovni
On Fri, Oct 16, 2020 at 02:37:04PM -0400, Demi M. Obenour wrote: > > Unless there's a particularly good reason why you believe that OpenSMTPD > > would do better than Postfix in bulk mail delivery performance, it is not > > helpful to recommend it here. > > I misunderstood your previous message,

Re: possible bottlenecks

2020-10-16 Thread Demi M. Obenour
On 10/16/20 2:10 PM, Viktor Dukhovni wrote: >> On Oct 16, 2020, at 3:14 PM, Demi M. Obenour wrote: >> >> I don’t recommend stock OpenSMTPD for security reasons, although I >> have some patches that make it much better in this regard. However, >> all of those relate to local deliveries. If you ca

Re: possible bottlenecks

2020-10-16 Thread Viktor Dukhovni
> On Oct 16, 2020, at 3:14 PM, Demi M. Obenour wrote: > > I don’t recommend stock OpenSMTPD for security reasons, although I > have some patches that make it much better in this regard. However, > all of those relate to local deliveries. If you can afford to disable > local deliveries, OpenSMTP

Re: possible bottlenecks

2020-10-16 Thread Demi M. Obenour
On 10/16/20 8:57 AM, @lbutlr wrote: > On 13 Oct 2020, at 22:47, Zsombor B wrote: >> I know this is a complicated question but what/where do you see possible >> bottlenecks in postfix? >> Is it CPU? RAM? Disk IO? > > In theory? Sure, any of those could be a bottle neck. On actuality, the > bottl

Re: possible bottlenecks

2020-10-16 Thread @lbutlr
On 13 Oct 2020, at 22:47, Zsombor B wrote: > I know this is a complicated question but what/where do you see possible > bottlenecks in postfix? > Is it CPU? RAM? Disk IO? In theory? Sure, any of those could be a bottle neck. On actuality, the bottles necks are processing spam if you receive mai

Re: possible bottlenecks

2020-10-14 Thread Wietse Venema
Zsombor B: > Hi, > > > I know this is a complicated question but what/where do you see > possible bottlenecks in postfix? > Is it CPU? RAM? Disk IO? > > I'm building an infra to send out ~3-5 million emails a day. That might have been challenging 25 years ago. As Viktor notes, the real chall

Re: possible bottlenecks

2020-10-14 Thread Viktor Dukhovni
On Wed, Oct 14, 2020 at 06:47:19AM +0200, Zsombor B wrote: > I know this is a complicated question but what/where do you see > possible bottlenecks in postfix? > Is it CPU? RAM? Disk IO? Whatever you have least of, relative to the workload you're expecting to process :-) Generally speaking you