By: Gabriel Ambuehl
posted: Monday 10 October 2005
This is a very flawed benchmark from an empirical point of view (it's
even worse than lies, damn lies, benchmarks, really), it HOWEVER has
some real world resemblance still considering that most people will run
it on hardware in the same general class which is really doing
something else, too!
On my Sempron64 2800+ workstation, I'm running PHP4.4+eaccelerator +
phplist feeding mails to postfix. With usual background load (some 30%
I'd guesstimate), phplist pushes about 3000 mails an hour, which is
just about 1 mail per second. (and no it's not postfix or IO limited,
outbound IO peaked at half my upstream).
As a longtime ezmlm user, that's truly disappointing to me, but
OTOH ezmlm serves a very different field (i.e. classical mailinglists
with the same message to everyone, perhaps minus VERP features).
They argue phplist is so slow because of all the customization it does
but then again, I don't think I actually need that! I wont have the
users unregister via link but rather via login to ezp which will have
the very same URL for all of them. If they cant remember the pw, ezp
will send it to them. If they wont bother with that, well they dont
deserve to unsubscribe, really.
What now? Truth to be told, I don't really know. The following options spring to mind:
- I was thinking that maybe I could force mailman to work with
ezpublish but then again, that one is a pain to get up running
correctly for people without MTA experience (I've set up my share of
mailservers but still struggle with it if I try to do weird stuff with
it).
- ezmlm is likely fastest of them all (maybe aside of spam
tools that have their own, multithreaded mini MTA) but even more so a
PITA as it only runs on qmail which is best filed under the "deprecated
MTA" category these days (tho for other reasons than why I'd put
sendmail there, obviously).
- Writing my own? The thought crossed my mind, obviously. But it
ain't easy, especially if you're not to use VERP for bounce handling
(discounting the lazy approach of just not dealing with bounces, of
course). Leaving bounce handling aside for the time being, the
following features would be a must:
- Multiple lists, same user subscribed to any number of them
- HTML
- maybe multipart with embedded images (I do have some reservations about that)
- Storage of users in a simple MySQL table, no 40 (!) tables like phplist
- Handling of archive is left to something else, i.e. ezpublish in my case.
- thus comes ezpublish integration
- means I want to have a "Send this content object" to that list option
- And finally, phplist's handling of external URLs is nice by any means but not necessarily needed from begin width.