Python performance

Chris Angelico rosuav at gmail.com
Fri Aug 2 09:43:33 EDT 2013


On Fri, Aug 2, 2013 at 2:16 PM, Schneider <js at globe.de> wrote:
> Queuing the mails for a while is not possible, because the tool should sit
> between the client and smtp-server.
> It should act as proxy, not as server.

I've written an SMTP proxy (primary purpose: check SPF records;
secondary purpose: rate-limit one particular PHP app) that can handle
fairly large throughput; it could probably saturate the network
connection it's working on (10Mbit) without the proxy making a
particularly notable blip on the CPU or RAM usage. Most of the work is
elsewhere.

How bursty will the mail be? If we're talking 2000 all at once and
then an hour of quietness, you may have some issues; but I'd say you
could do 100-200 in a second, on reasonable hardware. Of course, this
is assuming you're writing your logs to a write-cached volume - which
means you'll lose some stats if the power fails. If that's a problem
to you, you'll want to record your stats more reliably (personally I'd
let PostgreSQL worry about the details, ie store into a database),
which will cost throughput. But otherwise, basic stats shouldn't take
more than 5-10ms.

ChrisA



More information about the Python-list mailing list