In article <E0y0290-0003pK-00@???>,
Nigel Metheringham <Nigel.Metheringham@???> wrote:
>The real kicker for me is the performance. Our core boxes currently shift
>a few hundred thousand messages per day. An extra fork/exec would be
>painful. A fork/exec of a perl program would be *very* painful unless I
>could precompile it (which admittedly is just around the corner for
>serious use). The perl builtin would allow much higher performance and
>probably be easier to extend for "more interesting".
We may have come to a point where we need to look at allowing for two
different operating paradigms.
It's obvious that some users want lot's of filtering and have special
requirements. But's its also true that there are a some sites that
process a lot of mail and can only do so by being very careful about
what types of processing they allow.
So we have:
- high volume sites optimized to reduce per message handling
- low volume sites with lots of per message processing allowed
I predict that as mail volumes go up we may hit the wall as news and web
servers did a few years ago and require some rethinking of the forking
model for mail delivery. Probably going to either pre-forked or monolithic
process (with or without threads) models for high volume sites.
But there will also be a market for low volume sites that have many bells
and whistles to handle special requirements.
But they won't and can't be the same product.
--
Stuart Lynne <sl@???> 604-916-4741 <http://www.poste.com>
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 88 EC A3 EE 2D 1C 15 68
--
*** Exim information can be found at
http://www.exim.org/ ***
