On Thu, 15 Feb 2007, Alain Williams wrote: > Is there any reason why local delivery is single treaded ? With modern > multi CPU/core machines is might be nice to have a local_max_parallel > option. Especially where address expansion results in lots of local addresses.
The original implementation of Exim was single threaded for all deliveries; first the local ones (each in a separate subprocess, for security, which was waited for before continuting), then the remote ones (in the main delivery process, which changed from root to exim before doing this). Then remote_max_parallel was added - in Exim 3 it forked separate delivery processes only if there was more than one remote recipient. In Exim 4, it always forks, so the main delivery process no longer has to change its uid. The motivation for parallelizing remote deliveries was that a single delivery can take a long time, so even with as few as two remote recipients (to different servers), parallelism is a gain. My feeling at the time was that local deliveries are quick, so I didn't bother to change them. As far as I know, nobody else has questioned this. Multiple local deliveries into normal file mailboxes will often be hitting the same file system - whether this matters or not, I don't know. > This is my situation -- 4 CPU box & local delivery is to cyrus which > will have 'wait' time while it is speaking to active directory; so a > certain amount of parallel local delivery (in addition to batch_max) > would probably make sense. How are you delivering to cyrus? Using the lmtp transport? I suppose that is the one local transport that could cause substantial delays. (I guess pipe could too, if the pipe fills up...) -- Philip Hazel University of Cambridge Computing Service Get the Exim 4 book: http://www.uit.co.uk/exim-book -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
