2003-02-27T06:09:48 postfix-users:
> I have the task of setting up a mailserver capabel of sending 400
> 000 mail in a max time of 12 hours. All mails have an attachment
> of 1 mb.

Ouch. That's a lot of bits. 400GB. Viewed another way, that's very
close to 10 msgs/sec --- and email transmission to arbitrary sites
about the internet isn't flat, uniform and consistent, it's bumpy,
so to achieve that 12-hour mean you're probably going to need to be
able to achieve peaks rather higher. Let's say double, for purposes
of argument. 20MB/sec is c. 160Mbps. You're gonna be filling up four
T3s to the internet, pretty seriously, for a full half-day.

> The system should be a mailer for a newsletter system.

Thanks for mentioning that, providing us with an alternative to the
default "send lots of email --- you must be a spammer":-).

Ok, the hardest part of the job I'd have to defer to someone else;
you're gonna need some _serious_ network connectivity; you'll
probably want to be working with a big provider that has a mongo
net, and making special arrangements to pour your bits out.

Now a single postfix on a machine with plenty of RAM and fast disks
can sustain 20msgs/sec without too much pain. If you have to
customize each message for its recipient, it'll be rather more
painful. If on the other hand you can broadcast this thing with say
1000 recipients Bcc-ed on each injected message, then you'll only be
putting 400 messages through the queue, truly painless.

The hard part is that you're going to have to sustain a _lot_
of concurrency to get that much data pouring out; even if your
provider has provisioned you plenty of capacity and made adequate
arrangements to ensure you can enjoy good transit to plenty of good,
healthy, capacious peering points, you aren't going to expect to
deliver at rates exceeding 1-2Mbps to most hosts, and many hosts are
going to be a lot slower than that. So I think it's realistic to
expect that you're going to want to have a postfix lashup able to
sustain many hundreds, or better still several thousand, concurrent
SMTP sessions. This can still be done with one big server, but with
a need to sustain >>100Mbps output and many many connections, I'd
rather build a farm. Pick your box of choice; I like cheap 1U
rackmounts with at least 512MB RAM and two disks, for many jobs; it
seems to be a sweet spot in the price/performance tradeoff.

Set up a test platform with the exact OS and postfix build you want,
and do some tests with samples of your 1MB messages. You want to
find out the total VM footprint of each smtp process when sending
your message; and the equilibrium VM consumption of the whole rest
of the system. Arrange to leave however much headroom makes you
comfortable, 20% (100MB on a 512MB machine) might not be a bad first
guess if your message size is quite stable, and configure each
server to run that many concurrent smtpds.

Don't forget to provision a private DNS server farm. If your list of
recipients is quite stable, it might be worth manually downloading
the necessary MX and A records, and publishing them yourself
from a private authoritative root, accessed by separate caching
nameservers, a couple should suffice since you don't have to sustain
that high a query rate. If you have to use live internet DNS data
rather than a private mirror, beef up your caching nameserver farm;
slow DNS lookups will bog down your delivery something fierce,
forcing you to up the concurrency further to sustain the message
sending rates you need.

For these kind of message delivery rates, you've got to concentrate
on getting the messages out without delay to the servers that accept
them gracefully. You want to use the trick (which I can't seem to
remember or find in a quick trawl of the docs) to arrange your main
smtp server plant so it only tries each destination once, and any
recipients that can't be delivered to on the first try are handed
off to a separate server farm (with _lots_ of spool disk!) for
retries. Since destinations that fail once tend, on the average, to
be more likely to fail again than average sites, these retrying
boxes want to carry more concurrent smtp clients than your main
delivery boxes.

If you have any significant number of recipients in famously
hard-to-deliver domains, you'll probably want to manually configure
separate transports for those domains to tune their delivery by
hand.

No matter how you cut it, this is gonna be hard.

What would be a _lot_ easier would be to hire some serious
high-volume web content distribution company, Akamai or someone like
that, and get them publishing your 1MB newsletter from a zillion
servers all over the world, with clever hackery to try to sometimes
arrange to have clients hit "nearby" (in network speed) servers by
preference.

Then email out 400,000 1KB messages containing the URL of the
newsletter.

12-hour-sustained-mean 10 msgs/sec is not your problem, it's easy to
do that; your problem is 12-hour-sustained-mean 80Mbps. The internet
doesn't like to soak up bits that fast.

-Bennett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+XkffHZWg9mCTffwRAtBiAJ9u0G24Hh24qwfm4k0Uu9P0QyXMeQCffxTG
NOCyorAOjVCmdPbmVvr4VCc=
=7OTP
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]