[Mailman-Developers] problem with VERP stuffing all the messages in one connection

[Nigel Metheringham]

[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:
> 1) how many receipients in one Email (i.e. how many rcpt tos you sent per
>    mail from). That's already an option in mailman
> 2) 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 - ]