OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Relaying Performance
From: Greg Stark (gsstarkmit.edu)
Date: Sun Feb 06 2000 - 10:03:17 CST


wietseporcupine.org (Wietse Venema) writes:

> Gregory Stark:
> > To switch we would need postfix to accept mail over a handful of connections,
> > or ideally a single connection, at a rate of at least 20/s, preferably over
> > 100/s. Then be able to keep up delivering all the mail as fast as it's
> > received.
> >
> > Our initial experiments seemed to indicate that it couldn't deliver faster
> > than about 5/s. Is this just a simple tuning issue or are the numbers I'm
> > talking about simply infeasible with postfix?
>
> Postfix has a weak spot here where a lot of inbound mail can swamp
> all the I/O resources so that delivery rates drop. You can quite
> likely get more mail through Postfix by reducing the number of SMTP
> server processes.

But my feeder only opens a single connection and sends all the mail over that.
(Actually that's not strictly true, it reopens the connection after any error
and after 1000 successful deliveries.)

So a single smtp daemon is all we need. Besides, postfix was accepting mail
pretty quickly but not any faster than I would want in production. It was
accepting about 50/s.

Is there any support for having multiple levels of queues? Maybe it would help
if I kept the active queue on a memory filesystem and only once a message was
deferred move it to the real disks. In this application reliable delivery is
not a goal; if the system crashing means we lose a few hundred messages that's
fine.

Also, it would be good to try every deliver once with very short timeouts,
then defer it and handle it later with longer timeouts. The idea being to
limit the number of slots taken up by bad mail.

-- 
greg