Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have do some benchmarks with postfix, where we send out 6 KB HTML Mails. We followed all tuning instructions published by Postfix and used Ramdisk for the queue.

We was not able to send above 50 Mails / sec out.

Has anyone some input how we can improve that numbers?

The Server is only used for outgoing Mails.

Only to mention: I'm not a spammer :-) We will use it for a dating site where we send a big amount of Mails out for Notifications, weekly reports, daily stats.

share|improve this question
Here's a number to shoot for that I was able to achieve: 80 messages per second per core per GHz – MikeyB Dec 14 '11 at 19:12
@MikeyB will this work for our 6KB Mails too? This sounds too good, if I do the math correctly: 80 x 3 (Ghz) x 4 (cores) x 2 (cpu) = 1920 mails/sec if Hyperthreading x2 = 3840 mails/sec .... anyway both numbers sound very well and is really above what we need, but it will be great if we can push the mails fast out that the mail server has some idle time. – Nenad Dec 14 '11 at 21:12
My testing was done on mail mean 18KB in size on a 2x6-core 2.66GHz blade across 10GbE. YMMV, but you should be able to get MUCH more performance out of your hardware than you're getting now with proper concurrency. – MikeyB Dec 14 '11 at 22:18
Your problem will be bandwidth. Nothing else. – mailq Dec 14 '11 at 23:51

It sounds like you need greater concurrency.

First ensure that you aren't bound by disk activity. atop is a good interactive method for this. sar and other tools are available as well. Given the ramdisk, this shouldn't be the major issue.

If your queue is full of mail going to many different domains, that is a sign that you aren't running enough server processes. Bump the limit on how many smptd instances you spawn.

If your queue is full of mail to some of the big internet sites (tons of GMail, for example), you will need to tune your settings for single-host delivery. Postfix should ramp itself up if it has a lot of email to the same domain, though.

Investigate and let us know what you're seeing.

share|improve this answer
OK, thank you. I will prepare a new benchmark and try again. Last time we was go up to 16 processes (1 per core). Do you have a value that can be reached on a actual server (2x Quad core Xeon, 24GB Ram, 1gbps port)? – Nenad Dec 14 '11 at 17:37
Oh, wow... you need a lot more. Most of the time your mail delivery process is twiddling idle while it waits for network traffic. The default configuration allows for 100 mail transfer processes. Your server could probably run 1,000 handily. Start at 100 and work your way up. – Jeff Ferland Dec 14 '11 at 19:01
@nenad - Start at the default. Then 2x default. Then 3x, 4x, etc. - Continue until you have 3 runs that are (a) the same speed, or (b) progressively slower. The peak is at-or-near optimum performance (tune as needed from there if you're really pedantic.) – voretaq7 Dec 14 '11 at 19:42
I see, I need to spend some more time on postfix- I have put in the default_process_limit = 500 and default_destination_concurrency_limit=15 (to avoid to be blocked, do anyone know how much the big player like hotmail/gmail/aol will accept?) how I understand this need to do the job? I'm still not above the above throughput, I used 10'000 Mails to 10 different hosts (1000 per host) this means in my test i used 150 processes (10 hosts x 15 concurrency per host). Do I need touch any inside – Nenad Dec 14 '11 at 21:30

Having a DNS caching server on the mail server will help speed up deliveries as well. In fact, there have been many times in my environment where DNS lookups were THE bottleneck for mail delivery.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.