On 12-09-10 at 02:01pm, Thomas Goirand wrote: > During a discussion on upstream mailing list, I remember that one > person did some tests to check what was the optimum value for maxproc. > If I remember well, he told that 5 was the ideal value for a single > core CPU. > > So I wonder: how many cores did you run dkimproxy on? What did you do > to test the value of 10 instead of 5? > > I believe I should write in the README.Debian that the ideal value for > maxproc is "5 x number-of-cores", but I would like to be sure of what > I'm writing first.
My point is not that 10 is better than 5. My point is that setting DKIMproxy to 5 and Postfix to 10 is wrong: it works but quite inefficiently - if you don't care about queues being handled correct then why care about those numbers at all? On a related note, it only makes sense to limit _injections_ from Postfix to DKIMprox, not the returning postfix _daemons_. So all in all I recommend these two changes to documentation: * Change maxproc of dkimsign unix and pickup fifo to 5 * Change maxproc of 127.0.0.1:10029 inet and submission inet to - * Mention that the numbers 5 really correlate with those of DKIMproxy, so should also be adjusted in postfix config if changed in DKIMproxy config (Upstream seems to also not document the relationship, and also bofusly limits the return daemons, but at least with a higher value so the wrong-doing less frequently has an ill effect) Hope it makes better sense now. I disagree with your lowering severity (I find it not important but normal, because this is _ill_ documentation of _core_ functionality, not lack of it), but that's your call. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
