| 1 |
On Thu, 2005-19-05 at 09:45 -0500, kashani wrote: |
| 2 |
|
| 3 |
> Email throughput is highly dependent on how you're generating the |
| 4 |
> emails, RAM, disk I/O, number of emails sitting in your queue, how |
| 5 |
> you've ordered your emails, whether bounce handling is local or on |
| 6 |
> another server, spam filtering if any, and your server software. Even |
| 7 |
> the speed of your DNS server can start to play a part. |
| 8 |
|
| 9 |
This is all astute commentary. I agree with all of it. Fine tuning an |
| 10 |
email system (or any production platform) takes ... finesse. It's not |
| 11 |
about "installing this software or that software", but about |
| 12 |
understanding the behaviour of your system as a whole, and then tuning |
| 13 |
the performance from a position of knowledge, not from one of |
| 14 |
assumption. |
| 15 |
|
| 16 |
> 30/sec puts you a bit above 2.5 million a day which is probably the top |
| 17 |
> end of what you might see in the real world. |
| 18 |
|
| 19 |
Certainly seems a reasonable score. |
| 20 |
|
| 21 |
I've run 3-5 million emails a day through a platform based on Qmail. |
| 22 |
Qmail has architectural bottlenecks on how it processes new messages; |
| 23 |
likewise you need to take care to shunt traffic to misbehaving domains |
| 24 |
to alternate queues - but making it sing was little to do with Qmail |
| 25 |
itself and very much to do with knowing what the group of systems as a |
| 26 |
whole were doing and making informed judgements thereon. |
| 27 |
|
| 28 |
AfC |
| 29 |
Sydney |
| 30 |
|
| 31 |
-- |
| 32 |
Andrew Frederick Cowie |
| 33 |
|
| 34 |
Technology strategy, managing change, establishing procedures, |
| 35 |
and executing successful upgrades to mission critical business |
| 36 |
infrastructure. |
| 37 |
|
| 38 |
http://www.operationaldynamics.com/ |
| 39 |
|
| 40 |
Sydney New York Toronto London |
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-server@g.o mailing list |
Archives