On Wed, 1 Jan 2003, Kervin L. Pierre wrote: > Maybe you should seriously consider moving from back-shell to back-perl, > which you can optimize much more and is probably quicker right of the > bat, since it does not spawn a separate process for the interpreter. > > Better still, have you thought of back-meta or back-ldap? These were > designed for ldap routing.
Hmmm, good suggestions. I'd looked at the OpenLDAP 2.1 Admin Guide early on, and nothing in it jumped out at me as justifying going beyond 2.0.27 (the words "latest stable" have a warm glow about them...). If I'd known about these other back-ends I would probably have decided differently. Given that 2.1 is a big unknown to us (and it seems to want things like DB4 which we don't have experience with), I'm not keen on dropping it into production without some serious testing. Still, it sounds like just what we need. (On the subject of OpenLDAP and back-shell, I should also mention that we uncovered a nasty race condition that can lead to deadlocked shell subprocesses. The bug report and fix are at http://www.OpenLDAP.org/its/index.cgi?findid=2262) > I suspect you're optimizing the the wrong bottleneck. You are sooo right - I upped the saslauthd pool enough to prevent exhaustion, and we were fine for the first few days until the users came back. By about 9am Friday the CPU overhead of spawning all those perl processes had authentication timing out horribly (and the above-mentioned deadlock issue didn't help either). And that was just the start... In the end I reduced the load by hacking saslauthd (as described in my reply to Igor), which bought us time to write and test a C replacement for the perl. Of course the perl is much easier to understand and maintain, so going to a smart back-end is a better long-term solution. Oh well, live and learn... Thanks for the advice all the same! Simon Brady mailto:[EMAIL PROTECTED] Systems Specialist Ph. +64 3 479-5217 ITS Technical Services Fax +64 3 479-5080 University of Otago, Dunedin, New Zealand Mobile +64 27 411-6045