diff options
| author | manuel <manuel@mausz.at> | 2013-02-04 00:08:53 +0100 |
|---|---|---|
| committer | manuel <manuel@mausz.at> | 2013-02-04 00:08:53 +0100 |
| commit | 69aec538b456402170dc723af417ba5c05389c32 (patch) | |
| tree | e6f34c543f17c6392447ea337b2e2868212424d1 /BLURB4 | |
| download | qmail-69aec538b456402170dc723af417ba5c05389c32.tar.gz qmail-69aec538b456402170dc723af417ba5c05389c32.tar.bz2 qmail-69aec538b456402170dc723af417ba5c05389c32.zip | |
qmail 1.03 import
Diffstat (limited to 'BLURB4')
| -rw-r--r-- | BLURB4 | 44 |
1 files changed, 44 insertions, 0 deletions
| @@ -0,0 +1,44 @@ | |||
| 1 | qmail's modular, lightweight design and sensible queue management make | ||
| 2 | it the fastest available message transfer agent. Here's how it stacks up | ||
| 3 | against the competition in five different speed measurements. | ||
| 4 | |||
| 5 | * Scheduling: I sent a message to 8192 ``trash'' recipients on my home | ||
| 6 | machine. All the deliveries were done in a mere 78 seconds---a rate of | ||
| 7 | over 9 million deliveries a day! Compare this to the speed advertised | ||
| 8 | for Zmailer's scheduling: 1.1 million deliveries a day on a | ||
| 9 | SparcStation-10/50. (My home machine is a 16MB Pentium-100 under BSD/OS, | ||
| 10 | with the default qmail configuration. qmail's logs were piped through | ||
| 11 | accustamp and written to disk as usual.) | ||
| 12 | |||
| 13 | * Local mailing lists: When qmail is delivering a message to a mailbox, | ||
| 14 | it physically writes the message to disk before it announces success--- | ||
| 15 | that way, mail doesn't get lost if the power goes out. I tried sending a | ||
| 16 | message to 1024 local mailboxes on the same disk on my home machine; all | ||
| 17 | the deliveries were done in 25.5 seconds. That's more than 3.4 million | ||
| 18 | deliveries a day! Sending 1024 copies to a _single_ mailbox was just as | ||
| 19 | fast. Compare these figures to Zmailer's advertised rate for throwing | ||
| 20 | recipients away without even delivering the message---only 0.48 million | ||
| 21 | per day on the SparcStation. | ||
| 22 | |||
| 23 | * Mailing lists with remote recipients: qmail uses the same delivery | ||
| 24 | strategy that makes LSOFT's LSMTP so fast for outgoing mailing lists--- | ||
| 25 | you choose how many parallel SMTP connections you want to run, and qmail | ||
| 26 | runs exactly that many. Of course, performance varies depending on how | ||
| 27 | far away your recipients are. The advantage of qmail over other packages | ||
| 28 | is its smallness: for example, one Linux user is running 60 simultaneous | ||
| 29 | connections, without swapping, on a machine with just 16MB of memory! | ||
| 30 | |||
| 31 | * Separate local messages: What LSOFT doesn't tell you about LSMTP is | ||
| 32 | how many _separate_ messages it can handle in a day. Does it get bogged | ||
| 33 | down as the queue fills up? On my home machine, I disabled qmail's | ||
| 34 | deliveries and then sent 5000 separate messages to one recipient. The | ||
| 35 | messages were all safely written to the queue disk in 23 minutes, with | ||
| 36 | no slowdown as the queue filled up. After I reenabled deliveries, all | ||
| 37 | the messages were delivered to the recipient's mailbox in under 12 | ||
| 38 | minutes. End-to-end rate: more than 200000 individual messages a day! | ||
| 39 | |||
| 40 | * Overall performance: What really matters is how well qmail performs | ||
| 41 | with your mail load. Red Hat Software found one day that their mail hub, | ||
| 42 | a 48MB Pentium running sendmail 8.7, was running out of steam at 70000 | ||
| 43 | messages a day. They shifted the load to qmail---on a _smaller_ machine, | ||
| 44 | a 16MB 486/66---and now they're doing fine. | ||
