My team uses apache for our Subversion server, and apache is configured to authenticate users against an LDAP server.  After a recent upgrade from 2.2 to 2.4, we noticed that it would take longer and longer to check out a large repository.  We currently have the LDAPConnectionPoolTTL set to 0 to work around a separate issue, which turns out to be important.

I recently investigated and found that uldap_connection_find was taking more and more time, and that the number of entries in st->connections was increasing by one on each authentication request.  After stepping through the code with gdb, I noticed that the calls to apr_thread_mutex_trylock always indicate that they're busy.  Each call to the function traverses the entire list of connections (twice) and finds each one locked.  It then creates and returns a new entry.

Looking at uldap_connection_close, I see that the lock is released only if ldc->keep is non-zero.  But that field will be set to zero if st->connection_pool_ttl is zero, as it is in our configuration.  One way to fix the problem would be to shift the unlock operation out of the else block, and that does resolve the issue for us.  I'll attach a patch shortly.

It should be easy enough to reproduce this issue given access to an LDAP server.  Simply configure httpd to not pool connections, and time how long it takes to make a request that triggers the LDAP authentication.  Then make tens of thousands of such requests and test again.