[Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Patrick Ben Koetter]

* Barry Warsaw <barry at list.org>:
> On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote:
> 
> >I think it would be real nice to have a MILTER interface at LMTP server level
> >to allow mail modification as required. Mailman runs in large environments and
> >all the 'large organizations' I have worked asked my team and me to customize
> >how mail is processed. MILTER is a great interface to modify mail.
> 
> Do you mean a hook in Mailman's LMTP server process?  I thought about that in
> my previous message but decided not to mention it because it's not clear to me
> how performant Mailman's current smtpd-based (read: async) LMTP server is.
> What I mean is, I'm not sure how much additional work we want the LMTP server
> to do.
> 
> It would be cool if someone did some performance testing of the LMTP
> implementation, and it would be cool if someone tried to add some hooks into
> that server.  It might also be interesting to look into alternative
> implementations.  Another reason to push for getting Mailman 3 onto Python 3
> would be the ability to leverage Guido's Tulip work for better async IO
> performance.

We did a quick test and blew 10.000 messages into Mailman 3's LMTP server. The
hardware was/is a Pentium 2, 2 GB RAM machine with desktop discs - way below
current server hardware.

It took the test 25 min. to submit all messages:

real    25m10.041s
user    0m4.872s
sys     0m7.700s

That makes an average of 

400 msg/min or
6,6 msg/sec

Robert, who did the tests, Ralf and I agree that this is "way enough" for LMTP
server performance.

If we add a MILTER interface, the milter applications hooked into the LMTP
servers receiving process will slow down the income rate. The impact depends
on what the specific application tests or what kind of modification it applies
to the message. In general MILTERs are designed to work in memory only. No
message will need to be written to a disc, which usually is the most expensive
operation during mail processing.

At the moment we (at sys4.de) don't think it needs further testing, but we
offer to do so if you have reason to do so.

p at rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich