Re: [exim] Performance considerations

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Edgar Lovecraft
Fecha:  
A: exim-users
Asunto: Re: [exim] Performance considerations
Suresh Ramasubramanian wrote:
>

..[snip]...
>
> >>I'd like to read some (serious) documentation about what features have
> >>exim to reduce/optimize memory compsuntion due to its condition of
> >>being monolithic.
> >
> > umm, why don't you look into how shared memory is implemented
> > on modern un*x/linux/bsd systems before you assume that "monolithic"
> > == "bad".


I second that opinion.

> I think someone on his teem has been reading that comparison table on
> the qmail.org site ...


Also a note, the size of exim varies on what features you compile into
the binary, only compile those things that you need, as an example,
I have 3 different 'versions' of exim on three different servers, as
they all do different things, they do not need the same features, and
none of them need ALL of the features. (such as one machine talks only
to other internal exim servers, as such, it only accepts mail from those
servers, so there is no type of SMTP auth or encryption compiled in, as
the network it is on, is already private, even from clients)

here are the 'sizes' of the exim binary files as found by 'ls'
    the exim version is 4.34, and these all have perl compiled in,
    remove perl and the size reduces by '56276', remove LDAP support
    and drop the size by another '13730'


exim-1 662942 :: exim-2 659366 :: exim-3 689610

I am not going to say that the binary size is 'small', but 'small'
programs can have a very large memory footprint also.

Of course the standard sendmail binary as found in RedHat 8.0 has a size
of 819955.

Now I know that binary size, memory footprint, and such things do not
have a one-to-one correlation, but my point is really to just say that
your memory footprint with exim is going to have a direct correlation
to what features you actually compile into the binary, and don't forget
that if you use virus/spam scanners during the SMTP transaction, the
MTA memory footprint will basically be a non-issue, as the virus/spam
scanners are what is going to take up the system memory.

I can also say that I have never had any speed or memory problems with
exim, and I do service around 40,000 accounts.

Last note, I use exim, for many reasons, one, I have yet to find
something I either need, or want to do with an MTA that I cannot
implement with exim, the documentation is the best out there, and I find
it very easy to use and configure. I also find it nice that I do not
need to wade through hundreds of patches just to get the functionality
that I need or want (postfix and qmail have how many optional patches??),
as just a few of the reasons why I use exim over other MTA software.

--

--EAL--