[ On Wednesday, June 29, 2005 at 14:17:48 (+0200), Michael Haardt wrote: ]
> Subject: Re: [exim] High Perf server - was (exim allowed someone to slam my mail server for 3 hours)
>
> A better queue implementation would help a great deal. Possibly by
> using a special purpose filesystem, or by Exim working on a raw device
> or preallocated files.
If you think that's the problem then I suspsect you haven't done
any (or proper) measurements to understand the real problem.
It's not very difficult at all these days to buy very reliable
off-the-shelf I/O subsystems, which are not that expensive, and which
can easily out-perform (for queuing and de-queueing) any possbile
incoming SMTP traffic that can pass through a single 100baseT/FDX
interface (and if you have more traffic than that then you can easily
multiply the number of servers you split the load over until they're
each humming along happily without any restriction of the aggregate
throughput).
Don't forget that SMTP requires implementations to make commitments
about how reliably they can process message transactions.
Also rememer that not properly balancing other resource requirements
over other equally capable subsystems is a separate problem, and not one
that should ever require any fundamental changes to a good
general-purpose MTA in any way whatsoever.
And if your overall system design is too slow to handle the traffic
loads it is required to handle regardless of what hardware you throw at
it then you need to re-design your system more intelligently, not change
the MTA. For example using extremely high-overhead database queries to
look up what is 99.999% of the time just very small static records with
very easily normalized indexes is an extreme design oversight of the
worst kind and it will always lead to thoughput bottlenecks.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
