[Copied to exim-users - really for Philip's comments. Cross-posted replies will probably end up irritating the moderators :-) ]
On Fri, 2002-03-01 at 03:21, Marc MERLIN wrote:
Nope, there are two things:
- how many receipients in one Email (i.e. how many rcpt tos you sent per mail from). That's already an option in mailman
- how many mail from/rcpt to/data you shove through one SMTP connection. That hasn't been an option so far, but since most configs are set to send at least 10 to 100 RCPT TOs per MAIL FROM, you typically end up sending less than 100 DATAs (at least that's apparently been my case so far).
With VERP, I'm now hitting #2. A 500 user list generates a huge SMTP connection with 500 mail from/rcpt to/data. For exim, the default for smtp_accept_queue_per_connection is 10 (100 on my server), so after 10 batches in one connection (10 users with VERP or 1000 users with normal delivery and a batch size of 100), exim spools messages and leaves them to be picked up by the next qrunner, which may be run 15mn later.
Its a hard case here... you do really want that limit on exim for most stuff - otherwise you end up getting load averages that go sky high... Maybe the answer at present is to stop using that limit on exim but tune the load average limits so that if your box is thrashing you move to queue only (need to check *when* exim checks the load average).
The ideal would be to add the "queue only after n message transactions" to be some form of acl so that you could apply a different policy for localhost as to the rest of the world.
I'll definitely contribute exim documentation on how to tune the exim side (along with the updated directors and the exim 4 version of the directors), but I think we'd also kind of need:
It probably ought to be something like SMTP_MAX_SESSIONS_PER_CONNECTION.
which is probably the easiest route to solve... I'm undecided as to the theoretical "best" solution - all of this is compromises :-)
Nigel.-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ]