On Sat, 15 May 2010, Marc Perkel wrote:
> I just wrote up a tutorial on how to make Exim fast using a ram disk. It
> covers all the issues (I think). Let me know what you think. Mayby
> someone can improve it.
>
> http://wiki.exim.org/MakeEximFast
"Fast" is an absolute and has no tangible meaning, or rather, means
different things to different people. At the very least, I'd suggest
using "Faster" rather than "Fast". "make exim faster" would be a more
natural search engine query.
I'm not sure the editorial comment about your service and why your opinion
that "Exim is the best" is really relevant (I do not say that I disagree
:). All you need to say is "here are some techniques that I used to
optimise mail delivery" or somesuch.
The "simple script" doesn't say what operating system it is applicable to.
It looks Linux-y to me, but you should say so. It is very similar to a
FreeBSD rc script too (and maybe Solaris init scripts, from what I
remember of them), so it might be worth pointing out that some trivial
modifications could be made to make it suitable in those environments.
Abstract the paths to variables at the top of the script for easy
modification by end sites (the location of exim binaries and spools varies
a lot). Ideally, the queue location should be derived at run time from
the Exim config itsef, via exim -bP.
The Drawbacks section, particularly that you will lose mail if your server
goes down uncleanly needs to be much more prominent. I'd suggest this
drawback in particular should be mentioned right up at the top, with a
comment that this technique is only really applicable where loss of mail
is acceptable.
"should tell incoming servers to try a higher numbered MX record" -- say
'alternative', rather than 'higher numbered'.
I suggest proof-reading to find the typos.
Overall, I think this sort of information is useful, and there are
probably other optimisation tips that could be added (I'm sure there are
comments throughout the spec that draw reference to the resource
implications of certain techniques) but the significant drawback for your
particular mechanism case needs to be much more prominently highlighted.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK
