--On Monday, April 23, 2007 7:31 PM +0200 Pierangelo Masarati
I'd like to mention a different scenario, where proxy databases
deal with a mix of slow and fast targets. What we experienced is that
concurrency can be heavily penalized by this sort of mix of targets when
few threads are available, because inevitably operations affecting slow
targets eat up resources that remain idle in ldap_result() while they
could be used to deal with fast target related operations, while now they
have to remain pending. In some cases, we had to use up to 128 threads
(we even experimented with 512) with big waste of system resources.
A solution could be to redesign the proxies so that request and response
are handled independently by different threads, using "client"
connections that detect activities on persistent connection handlers
towards the targets. Together with a customer, we quickly prototyped
something like this (back-aldap, standing for "asynchronous ldap"), which
is just a toy right now, but it showed some potential.
In the meanwhile, I'd like slapd to maintain as much efficiency as
possible when running with lots of threads.
Right, there are cases where more threads are necessary. But I think the
default value of 16 is too high for the majority of cases. This is exactly
the sort of case that should be well documented. I'm somewhat working on
in my mind an FAQ entry on OpenLDAP tuning putting together the various
bits I've gleaned over the years.
Senior Systems Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html