|
The threads configuration parameter controls the size of the pool of threads used to process LDAP operations. The default value (16) has been found to be reasonable for most platforms, and most deployment scenarios. In some cases, the server may perform better if it lowered. In a few cases (such as systems with many (>=4) CPUs), a higher number may be better. High values (even 32) may cause resource exhaustion and/or significant resource contention.
One should bench the server under load before and after the change to see if the change had any significant impact. Unless the benching indicates that the
change resulted in significant improvement, the change should be undone.
|
If using back-ldap or back-meta to map a virtual naming context onto a real naming context that is managed by the same slapd, one must consider that for each operation a thread will be used by the proxy and one by the database that is actually storing the real naming context and thus the real data. As such, the number of concurrent operations is roughly half that indicated by the threads statement.
In 2.3, back-relay exploits the internal structure of the backends to perform the virtual to real naming context mapping without passing thru the client library layer used by back-ldap and back-meta when the real naming context is stored in the same slapd that implements the virtual naming context. This should yield better performances, and definitely use only one thread per operation. The naming context rewriting (and attribute mapping) for back-relay and back-ldap is performed by the rwm overlay, while back-meta still performs the rewriting/remapping internally.
|
OpenLDAP Faq-O-Matic : 
What should the "threads" configuration parameter be set to?