Author: W B Hacker Date: To: exim users Subject: Re: [exim] Fastest Exim server ever
Marc Perkel wrote: >
> Ken Price wrote:
>>> The MTA has to be able to receive 50k/second in bursts and get them out
>>> as quick as possible. Probably not as fast as coming in but from what I
>>> understand delivery speed is important.
>>> It's coming from some sort of SQL server that they say can deliver it
>>> that fast.
>>>
>> Don't think one server. Think multiple, less powerful servers. 50k
>> unique messages a second isn't a realistic goal from a single server.
>> Theoretically, you're talking 50k outbound connections to remote MX
>> servers.
>>
>> Also, and I hate saying this, but the advanced features, flexibility,
>> and functionality that make Exim so great will also hinder you. You
>> don't need a full blown MTA here. Don't hate me, but I REALLY
>> recommend Qmail in this application. It's fast, lightweight, and for
>> this application ... simple. Might as well go with djbdns on the
>> local machines for DNS caching, too.
>>
>> I don't typically recommend D. J. Bernstein software, but I think it's
>> the right choice here.
>>
>> My 2 cents.
>>
>>
>
> I just can't stand Qmail. I wish it would just die. When Qmail sees a
> 421 response it doesn't retry the higher MX which in my mind makes it
> totally unacceptable. But thanks for the suggestion.
Whether one 'likes' Qmail or not - it was/is a 'one trick pony'.
While massively parallel sends from the same source-IP to *separate*
destination IP may still work, in today's environment, Qmail falls on
its face when it tries to send even five or ten messages to the same
destination IP over five connections instead of ONE.
That because a fairly effective zombot limiter is to defer all after the
third simultaneous connection from a single IP.
Ergo, Qmail's 'speed' turns bass-ackwards.
Any other MTA has delivered all five in one go, while Qmail still has
retrys to do...
As Judge Roy Bean said "*Justice*, you son of a b--"
;-)
>
> Yes - we will go wide if need be using multiple servers in parallel.
> Going to start with an Intel Quad core and 8 gigs of ram.
Only if you buy the top-end Xeon and MB 'glue' that can *use* over 4GB.
Remember, Intel 'commodity' CPU only have 64-bit *extensions*.
NIC's and storage controllers don't DMA into the voltage regulator
chipsets - they need RAM and address space.
For affordable Core-2 Quad, calculate as:
(4 GB minus reserves for VGA and bus denizens)
- e.g about 3 1/4 GB with decent VGA, 3 3/4 GB if headless.
Any more RAM wanted, you'll be better off with AMD-64, UltraSparc, HPPA
(PA-RISC/Itanium), Power5/6, roughly in order of increasing cost.
And it isn't just the architecture - the 'commodity' OS'en most of us
here use don't all handle the above-4GB RAM as fast as the below-4GB RAM.
> Put the queue
> in ram and if the first attempt fail it goes to a secondary server for
> retries. And have a dedicated DNS server for fast lookups. I'm going to
> keep the config as small and simple as possible. But just looking for
> some stats to see if anyone else ever did anything like this.
>
I've done enough stuff 'of a similar nature', even to having dedicated
submarine fiber cables available to test with, to say that your first
purchase should be pencil and paper or a desk calculator, rather than a
server, and that your first hour of labor a bit of Googling for I/O
benchmarks and doing the math.
What will save yourtechnicalazz is that the load will probably never
materialize.
OTOH, that also means you probably won't be paid.
Best to make sure youreconomicazz is covered with up-front 'setup' money.
