Andrew McNamara writes:
My experience has been that Postfix is very fast and uses considerably
less resources than some other options. Postfix's design criterion were
security first, then performance. It tries to be sendmail compatible
where that doesn't compromise security or performance.
What in particular suggested to you that it might be slow and resource
hungry?
For those that don't know postfix, it uses separate small persistent
processes that don't trust each other (somewhat like the qmail model).
That's the reason for my impression of postfix. When you segregate things
to such an extent, you add more overhead. If you use a separate process
that's dedicated just to rewriting headers, this means that just for the
purpose of rewriting headers you now need to open a file, read it, and then
create a new file.
That's a terrible overhead, and there's no need for this. Courier rewrites
headers on the wire, as it receives and sends a message, before or after it
writes or reads the file containing the message's contents. While it's
occupied with rewriting the headers, the kernel can be busy receiving the
rest of the message. Seems to me that this would be much more efficient
than receiving the message, saving it to a file, then reopening the file in
another process, reading the message, rewriting its headers, creating a new
file, deleting the old file.
It supports multiple recipients per smtp transaction (unlike qmail),
and pipelining, so it's kind on the network. Communications between
daemons is done in sensible ways, so the extra context switches are
barely noticed.
You probably have to strain yourself to notice any context switches with
the CPU clock rate in the gigahertz range. I think that Postfix's resource
demands will probably be more pronounced on low-end machines.
5 messages in net.sourceforge.lists.courier-users[courier-users] Re: POSTFIX, WAS: RFC...
