When a proxy (back-ldap, back-meta) sustains heavy traffic using the proxy's rootdn, a single connection has to do all the work. Should we consider using a (configurable) pool of connections, instead of just one?
The proxy itself could be reworked using a different approach: cache connections, with an idle-timeout, based on the connection's DN; a pool of connections could be used if necessary. This would allow to use a persistent (pool of) connection(s) for binds instead of creating one each time. Any time a bind succeeds for a DN that is not in the cache yet, the LDAP* handler would be used for that identity; a new bind handler would need to be created as soon as required. If a pool of connections is used for binds, the handler would just need to be removed from the pool; pool balancing would determine if a new one has to be created when required. Connection pool balancing (anonymous, rootdn, bind; per-DN pool if appropriate) could be based on a fixed size, or on some algorithm based on the lc_refcnt of the active connections. Repeated operations with the same set of identities would require to create: 1 connection for all binds (serialized; could be a pool of connections) 1 connection per identity (could be a pool of connections as well) right now we create: 1 connection for each bind, which remains around for the duration of the client connection. So in a scenario where multiple connections occur always with the same (small) set of identities the improvements should be apparent. p. Ing. Pierangelo Masarati Responsabile Open Solution 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: [EMAIL PROTECTED] ------------------------------------------
