Re: [exim] Fastest Exim server ever

Marc Perkel wrote:
> OK - without questioning why they need to send email that fast, my
> thinking on how to do it is this.

*snip*

Marc,

Before wasting any more of your time - or ours - on it, it would be
'prudent' to go off and get more information for yourself.

A great deal more.

Aside from ascertaining if the 'wisher' can even afford the initial cost
to *start* implementing their plan, and over what period of time it is
expected to ramp to that magical 50,000 per-second level, defining
appropriate technology dictates that you need to know what size of
messages, where from, where to, and whether every message is unique, or
if there are many copies of the same content in each of many 'bursts'.

My gut feeling, from your OP that this may be a 'games' app, indicates
that http(s) technology might be a better fit - i.e. a portion of each
player's screen where <whatever> was projected to arrive by smtp is
displayed and updated instead of going through all the smtp handshakes
and intervening differences in what various MTA, ISP's, and backbone
carriers allow/disallow/throttle.

That, for starters, at least limits the load to the 'active' player
community, and further distributes at least a portion of the resource
usage to each player's machine.

*Neither* approach may be appropriate - too little known about the
actual plan.

>
> Start with a computer with as much ram as possible.

~ 2 TB / rack (big-iron)

;-)

Or were you thinking of an AMD MB?

Tyan quad-socket with riser for another four sockets - max 128 GB, 64
GB/board.

And you can start off with one Quad-core Barcelona and its 16GB (or
less), add CPU, RAM, and riser MB as needed.

> Create a ram dis for
> the queues and no log files so there is virtually no disk access.

Dumb move, and not needed. The disk I/O isn't the critical path.

The gadzillion smtp handshakes with timing determined by network and
far-end servers is the greater challenge.

> Also
> have a second server for caching DNS and as a backup server in case
> email is delayed. The idea is to use the second server as a fallback
> server. The first main server tries to deliver the message only once. If
> it fails on the first try it hands it off to the second server and that
> clears it out of the queue.
>

What about the request for a pony?

> Yes I know that if the first server loses power that you would lose
> everything in the queue but I think it's acceptable.

Not acceptable at all if this is a 'revenue' based model to the client.

> Then the Exim
> config would be as simple as possible and have it tuned for speed.
>

Exim 'simple as possible..' and '..tuned for speed' is some other MTA.

Exim is an experienced French Chef who cooks whatever is asked for.
You give such folks time to do the job right.

The 'fast' MTA flings biscuits from a manure-spreader.
You pray it was biscuits they loaded up with.

All else sits between those extremes.

> Would you all say that would be the way to make Exim as fast as it could
> possibly go?
>
>

I think most of us would say 'why bother'.

IF/AS/WHEN Exim is not fast enough, (bloody seldom, if scanners are left
out of the equation) we are more likely to parallel rather ordinary servers.

That because - 'speed' quite aside - we dare not put so many eggs in one
basket that failure means you have to leave the country to stay alive.

Bill