Exim is a general purpose mail programme.
Like most general purpose things, it may have lower performance under
some conditions than a thing designed for that specific set of
conditions. All systems have some level of trade offs.
Exim puts mail through an on-disk queue, and, obeying the appropriate
RFCs, takes great care to make sure that received mail is committed to
stable storage before acknowledging receipt or attempting further
delivery - this tends to require round trips, not just to the disk
controller, but right down to the spinning rust, so will limit
performance, whilst enhancing reliability.
Marc Perkel wrote:
> What I found works best is to put the exim queue in a ram disk ...
Of course you can throw away those guarantees, it depends whether you
care that you will lose mail if the system exim is running on crashes,
loses power or has some other hard outage.
Similarly, if you are sending out bulk mail, it generally is either many
identical messages, or many messages effectively identical but with a
little bit of template replacement done to it (ie Dear $Sucker etc). If
this is the case you don't need to worry about all this queue
management, disk file and other baloney - you get the message in memory
(shared across a number of delivery processes, or maybe using an event
driven single process design), connect to recipients, and bang a
template processed message out, all without going anywhere near the disk
subsystem. Much faster *for* *this* *specific* *application*.
So, unless someone has specific figures to show that there are
performance issues that can be addressed without compromising other
requirements, I suggest we call this subject closed.
[The thread is already on moderation, and I'm going to tighten the
moderation criteria to require "useful new contribution" as well as the
normal requirements of a degree of good behaviour and relevance]
Nigel.
--
[ Nigel Metheringham ------------------------------ nigel@??? ]
[ Ellipsis Intangible Technologies ]
