Johan Pappu:
> ok. The application profile is as follows
>
> 1) It is an xml api which is written in php.
> 2) It sends email to all recepients specified in <to> tag
> 3) We use mysql. It not on server where we have installed postfix. It's on
> the application server.
> The flow of application is as follows
>
> we have set of high end servers where we install the postfix. and one
> application server where we have application deployed.
> The application establishes the TCP connection using fputs() function of php
> and sends mail to the server where postfix is been installed then postfix
> sends the mail. We haven't installed any mysql or httpd where postfix is
> installed to keep memory usages of that server low. both application server
> and postfix server is in LAN
OK, so you want Postfix to receive and send 300+/second over a
time span of five minutes.
The nearest real-life experience I know of is Victor Duchovni's
experiments, from around the time that he was sending out email
concerning a major IPO stock offering.
Citing from a posting in 2004:
Date: Tue, 15 Jun 2004 07:34:09 -0400 (EDT)
From: victor.ducho...@morganstanley.com
Reply-To: postfix-users@postfix.org
To: Postfix Users List <postfix-users@postfix.org>
Subject: Re: AW: AW: Any numbers of how much traffic postfix can handle?
[text skipped]
As for Postfix performance numbers, I just reran my test on a
Dell 2650 with Perc 3Di RAID controller mirroring and write
caching for 2 physical OS and 2 physical data drives (1 logical
OS + 1 logical data).
smtp source (4 sessions) -> Postfix 2.1.1 -> sink (50 cached
sessions)
The output rate keeps up with the input rate at up to 400
messages/sec. Once the output rate rises over 400/s (by raising
the number of source sessions) the output rate drops to ~200/s
with input running near ~600/s, later when the input ceases,
the queue backlog drains at ~1000/s.
This uses the Postfix smtp-source program to generate parallel mail
streams into Postfix, and smtp-sink to receive (and discard) the
mail. It used 50 concurrent SMTP sessions into smtp-sink that were
kept open with the Postfix connection caching feature.
Suggested strategy:
1 - Reproduce the above numbers with smtp-source and smtp-sink.
2 - Replace smtp-source with your PHP application, and tune this
until you can reproduce the smtp-source performance level.
3 - Replace smtp-sink by the Internet. All comments made on this
list regarding DNS latency, SMTP latency, and remote server
throttling are valid. These are going to be your biggest
challenge; the only control you have are local DNS caching,
over-all concurrency, careful per-destination concurrency
scheduling, and sender reputation (proper DNS, DKIM, SPF, and
whatever seems to help). SMTP connection caching will help
only in some cases.
Have fun.
Wietse
