I'm facing the problem of having too many threads operating on the same privileged connections in back-ldap/back-meta, which seems to cause poor scalability. This mainly occurs because we want all operations to be performed as a privileged identity with proxyAuthz. For this purpose I plan to move privileged connections out of the connection AVL tree into ldapinfo_t, so that we save a search in the tree, and keep multiple instances of privileged connections in a LDAP_TAILQ structure of fixed maximum length to use them round-robin. Each type of privileged connection uses a dedicated list, so in our case we basically keep two lists: one for the privileged user and one for binds, which are now serialized into one privileged connection since all subsequent operations use proxyAuthz. A prototype is being tested, which doesn't work too bad (scalability did not dramatically improve yet, so there might be other bottlenecks, but at least some repeatable transient hangs disappeared). Comments?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote:
I'm facing the problem of having too many threads operating on the same privileged connections in back-ldap/back-meta, which seems to cause poor scalability. This mainly occurs because we want all operations to be performed as a privileged identity with proxyAuthz. For this purpose I plan to move privileged connections out of the connection AVL tree into ldapinfo_t, so that we save a search in the tree, and keep multiple instances of privileged connections in a LDAP_TAILQ structure of fixed maximum length to use them round-robin. Each type of privileged connection uses a dedicated list, so in our case we basically keep two lists: one for the privileged user and one for binds, which are now serialized into one privileged connection since all subsequent operations use proxyAuthz. A prototype is being tested, which doesn't work too bad (scalability did not dramatically improve yet, so there might be other bottlenecks, but at least some repeatable transient hangs disappeared). Comments?
Sounds like that will work well. If the target server is an OpenLDAP server, it will limit the number of concurrently executing ops on a connection, which would definitely create a bottleneck using just one privileged connection. Likewise, distributing requests across multiple connections will reduce mutex contention in libldap_r, so that should also be a win.
-
Howard Chu -
Pierangelo Masarati