On Tue, 7 Sep 2004, Peter Savitch wrote:
> The main drawbacks of Exim:
> - poor ability to handle large mail queues, not the memory;
As I say whenever I talk about Exim, it was designed for an environment
where over 95% of messages are delivered right away - which was and is
the case in our environment. The queueing state is intended to be the
exception state, and so Exim does not perform well with large queues.
Of course, mail volumes have increased enormously and even 5% of mail
volume is a lot more now than it was in 1995.
> - inability to share the queue between multiple boxes (questionable
> scalability);
The wisdom of doing this has already been questioned by Suresh. However,
if you want to do it, you probably can. Put the queue on an NFS server,
and set localhost_number on each host. I DO NOT, repeat DO NOT, recommend
doing this. DO NOT do it! Quite apart from being sure that it will
actually work, having many hosts accessing the same disks introduces yet
more bottlenecks. And, as Exim does not work well with large queues,
having a single large queue will make it even worse.
Exim is disk-access limited. The general rule for an Exim installation
is to spread it over as many different physical disks as you can, so as
to have the maximum I/O bandwidth.
As far as scalability goes, there are ISPs handling millions of messages
a day with millions of customers, and they do it with Exim. What they
usually do is implement a multi-level system so that queues on the
front-line delivery hosts are always short. Fallback hosts are used to
hold the queues. Multiple levels can be used, e.g. one try on a main
delivery host, try for 6 hours on the first level fallback, then shunt
over to another level where the performance may be bad but it doesn't
matter at that stage.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
