Re: [EXIM] Largest volume EXIM installation?

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Nigel Metheringham
Fecha:  
A: Dom Mitchell
Cc: Vincent Renardias, Evan Leibovitch, Exim Users Mailing List
Asunto: Re: [EXIM] Largest volume EXIM installation?
} > My main problem with qmail (which made me switch to exim) is that it's not
} > conservative w.r.t. bandwidth; ie: if you host a mailing-list where 20
} > users are subscribed from the same remote host, qmail will open 20 SMTP
} > connections to the remote host, while exim will use only 1 SMTP
} > connection.
}
} This is a highly debatable point, which I have yet to see resolved
} satisfactorily.

Actually the more significant point is that given a number of recipients
on a single destination host, exim will perform a single SMTP transaction
with multiple recipients, qmail will perform n SMTP sessions each with one
recipient.

Dan has clearly stated that qmail's primary optimization is for minimum
latency (interestingly his approach can actually increase latency under
some conditions, but I am willing to admit that you are probably talking
about contrived test cases here). Qmail achieves low latency by firing
off deliveries as quickly as possible and this is at the expense of
bandwidth conservation. Exim routes all the addresses before starting to
deliver any of them (hence higher initial latency), but can then optimize
delivery in ways that qmail cannot.

Dan maintains that bandwidth conservation is pointless - bandwidth is
cheap - and also questions whether there are really the gains that people
claim by multiple rcpt to's. On mailing list systems the bandwidth saved
is substantial - somewhere back in the exim archives there should be a
message from me giving the figures for the exim lists. On our core mail
systems I have to admit that this is all a bit marginal - bandwidth
savings are probably of the order of a few percent (if you are really
interested I could try to analyze). However the other advantages of
knowing about all your addresses before you transport still kick in - we
abuse systems that have had temporary outages less than a qmail system
would (latency here plays off against network friendliness).

The qmail VERP list handling stuff trades off bandwidth against
tracability. At times, as someone who runs a list, I would have killed
for this....

You can parallel deliveries in exim to increase performance, this is
somewhat different to what qmail does.

[Just to make something clear. I keep referring to "Dan", meaning Dan
Bernstein, creator of qmail, because he gave a clear well thought out
rational when he first announced qmail. I am not interested in getting
involved in some form of personal attack on him - I don't always agree
with him and we obviously have different priorities - some of which can be
explained by the difference in UK/European and USA computing/netorking
environments. Qmail is a *very* good mailer, it just uses a model which I
don't think fits my requirements. In the same way I happen to be an
Xemacs user, others swear by/at vi. There is room in the world for more
than one mailer or editor. [OK Emacs will of course try to be the only
editor, mailer, working-environment....] ]

[what a long rant for an early morning]

    Nigel.
-- 
[ Nigel.Metheringham@???   -  Systems Software Engineer ]
[ Tel : +44 113 207 6112                   Fax : +44 113 234 6065 ]
[      Real life is but a pale imitation of a Dilbert strip       ]




--
*** Exim information can be found at http://www.exim.org/ ***