Re: [exim] What's the performance benchmark of Exim4?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Graeme Fowler
Date:  
À: exim-users
Sujet: Re: [exim] What's the performance benchmark of Exim4?
On 23 Aug 2013, at 04:11, boyd yang <boyd.yang@???> wrote:
> I was not right about the "1000 concurrent connections" in the above email.
>
> Here is my performance test result.


You really need to define what it is you're trying to measure in terms of performance here.

Exim, as a piece of software, is bound implicitly to the limits imposed by the system it runs on. In one of your previous messages you posted a load of log data which showed that either:

1. The system was running out of memory, or
2. The system was imposing limits on the user Exim is running as, to ensure that it didn't kill the system.

As there's no "standard" way of running Exim, nor a "standard" hardware setup, it is impossible to realistically quantify limits or benchmarks.

For reference, at work we have four MX hosts used for inbound email and two "outbound" (more correctly, inter-system) MTAs used for outbound. Our clients use Exchange, which pumps all of its mail to external systems through the MTAs. They barely break a sweat, despite having throughput peaks in the 100s to 1000s of messages/second (it's normally much, much lower).

That, however, is our system - not yours. We impose rlimits through /etc/security/limits.conf to make sure Exim can't completely kill the system (although they can be brutal if invoked), and we have a reasonable idea how well our systems perform in real life so have sized a little "bigger" to handle peaks.

Personally, I think you need to step back and ask the following questions:

1. What am I trying to achieve, and
2. How should I configure my system to achieve that with room to spare?

That's a pair of sysadmin questions, rather than specifically related to Exim. You might need an SSD for disk throughput, for example, or a filesystem which could deal with masses of small files well, or a well-tuned array of fiber-channel drives, or lots of RAM, or huge numbers of CPU cores.

Or you might not!

Graeme