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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
