[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.5

Howard Chu wrote:
Brett @Google wrote:

Perhaps the ability to run a backend(s) in a seperate thread of execution, and
also maybe the ability to run arbitrary threads in the server core for things
such as cache managment, without having to implement a backend.

We tried cache pruning in a separate thread before. It doesn't make anything
faster. Threads aren't a magic solution to everything. Frequently they're not
the solution to *anything*.

Just to clarify - in back-bdb/hdb, we tried putting the cache pruning in a separate thread. The problem was that if the cache was full and the slapd was fully loaded, it was very likely that the cache thread would not get a chance to run until long after the cache had grown too large. Thread scheduling is non-deterministic, and if there are a lot of LDAP requests going into the thread pool, you can't guess when the cache thread will get to start, and have no idea when it will finish.

In the pcache overlay, cache pruning still runs in a separate thread. While the same constraints apply, the actual job is different, so it works fine.

As for "cache management, without having to implement a backend" - isn't that exactly what the pcache overlay provides? What are you asking about?
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/