Re: [Mailman-Developers] [PATCH] MTA patch for sendmail/qmail
julian7@kva.hu said:
This patch's goal is to use the sendmail-interface rather than use the SMTP port managing to send letters. This method is much more effective when the SMTP server itself is in the local machine. (due of the latency of establishing a socket)
I find this *very* strange - I would expect the process startup hit to be a real performance limiter in this situation. However some of the differences in the way that qmail runs as opposed to a sendmail or similar MTA daemon may well mean that this method works for qmail.
Certainly the latency to connect to a loopback network socket should be minimal (as long as no one starts trying to do strange things like remote DNS reverse lookups of 127.0.0.1).
Other downsides are the inability to deal with errors relating to a single recipient other than by a bounce message (ie no per recipient turnround message).
Actually maybe thats the latency you are referring to - in an SMTP transaction you *should* wait after each RCPT TO for a return code, so each recipient would have a turnround time and a couple of process context switches. If the MTA supports streaming (ESMTP required) then you could blat the recipients across without waiting for turnround - you can't just fire them in a pile because its possible you could get a double blocking leading to deadly embrace - and then check the return codes separately. [I haven't checked through the python code to see exactly whats happening here]
Nigel.
-- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]
On Wed, 15 Sep 1999, Nigel Metheringham wrote:
I find this *very* strange - I would expect the process startup hit to be a real performance limiter in this situation. However some of the differences in the way that qmail runs as opposed to a sendmail or similar MTA daemon may well mean that this method works for qmail.
Well, qmail just put the mail to the queue. If you use SMTP directly, you have to deal with connection failures, error codes etc (== you have to use an own queue other than the MTA). *This* is the deal.
Certainly the latency to connect to a loopback network socket should be minimal (as long as no one starts trying to do strange things like remote DNS reverse lookups of 127.0.0.1).
Sure - this can be true for sendmail giant, but the slimmer commands doesn't allocate loads of memory, doesn't parse big files. If you use SMTP port, firstly you open that connection, an inetd/tcpserver calls a qmail-smtpd, which calls a qmail-inject, besides of the local delivery, which only calls qmail-inject.
Other downsides are the inability to deal with errors relating to a single recipient other than by a bounce message (ie no per recipient turnround message).
Yeah. But your method doesn't work for a lot of addresses too. IMHO that solution doesn't work effectively.
Regards: Kevin (Balazs)
participants (2)
-
Balazs Nagy
-
Nigel Metheringham