On Thu, 2014-07-31 at 01:56 +0000, Viktor Dukhovni wrote: > On Thu, Jul 31, 2014 at 12:07:18AM +0100, Andrew Beverley wrote: > > On Wed, 2014-07-30 at 22:43 +0000, Viktor Dukhovni wrote: > > > Connection re-use does not prevent concurrency, you'd need a pool > > > of connections or parallel submission processes pulling messages > > > from the application queue. Concurrency is more important than > > > connection re-use. > > > > Ah, okay. Is default_process_limit the correct setting to be looking at > > here? I have it set to the default of 100. The maxproc of the smtp unix > > service in master.cf is set to the default. > > You've suddenly switched topics from message injection, for which > the default limits are more than ample to global process limits, > which for an MTA that mostly sends control delivery concurrency.
Sorry, I misunderstood. When you say I'd need "a pool of connections or parallel submission processes pulling messages from the application queue", you mean within the actual application sending the emails to Postfix? If so, the server is serving lots of different email lists, and there are 10 threads which pick up and deliver email for the lists. Therefore, I anticipate that each thread will deliver serially, but that there could be 10 threads doing so in parallel. > Did you mean to switch topics? Erm, no... that is a good demonstration of why I was looking for a consultant ;-) That said, I am keen to understand, so I appreciate your help. > Delivery concurrency is a much more complex topic, a lot depends on > your hardware and network, as well who you send mail to and how much > they push back... Ditto. > > I notice that maxproc of some other services in master.cf is set to 1 or > > 0, rather than the default of 100 (eg pickup: 1, cleanup: 0, qmgr: 1). > > Is this normal? > > Essential. Leave the limits that are 0 or 1 set to 0 or 1. Other > limits are tunable. Okay, thanks, Andy
