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

Re: Caching queries



Tony Earnshaw wrote:
Buchan Milne skrev, on 08-02-2008 16:29:

[...]

DESCRIPTION
        The  pcache  overlay to slapd(8) allows caching of LDAP search requests
        (queries) in a local database.  For an incoming query, the proxy  cache
        determines its corresponding template. If the template was specified as
        cacheable using the proxytemplate directive and  the  request  is  conâ
        tained  in a cached request, it is answered from the proxy cache.  Othâ
        erwise, the search is performed as usual and cacheable  search  results
        are saved in the cache for use in future queries.

[...]

Or, are you implying that pcache is broken in 2.3.3x (I don't use it myself).

"Well", he answered cautiously, "it (at least the 2.4 man page) also goes on to say:

CAVEATS
Caching data is prone to inconsistencies because updates on the remote
server will not be reflected in the response of the cache at least (and
at most) for the duration of the proxytemplate TTL."

The general acceptance of any-brand query caching by LDAP "experts" such
as Victor Duchovny of Postfix fame is that ... leave it alone, we don't
support it, if you try it and it doesn't work, then I don't want to know.

And that's a safe and reasonable answer from someone who doesn't understand the material and doesn't want to learn about it.


My original answer to OP still stands: he should get equivalent
functionality from connection caching.

No. Connection caching is helpful but it's nowhere near as effective at boosting performance. Still, you need to have many factors working in your favor before you can safely do query caching. E.g., all of the querying clients must have equivalent privileges on the remote server, otherwise some clients may get incomplete results from the cache, while others may get excess results (info they would not otherwise have access to). You need to understand how frequently the remote data changes, and how frequently it's accessed, so that you can set a useful TTL on the cached data. It is certainly error prone if you don't take the time to study your environment before deploying it.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/