2 # Copyright 2003, The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
5 H1: The Proxy Cache Engine
7 LDAP servers typically hold one or more subtrees of a DIT. Replica
8 (or shadow) servers hold shadow copies of entries held by one or
9 more master servers. Changes are propagated from the master server
10 to replica (slave) servers using LDAP Sync or {{slurpd}}(8). An
11 LDAP cache is a special type of replica which holds entries
12 corresponding to search filters instead of subtrees.
16 The proxy cache extension of slapd is designed to improve the
17 responseiveness of the ldap and meta backends. It handles a search
19 by first determining whether it is contained in any cached search
20 filter. Contained requests are answered from the proxy cache's local
21 database. Other requests are passed on to the underlying ldap or
22 meta backend and processed as usual.
24 E.g. {{EX:(shoesize>=9)}} is contained in {{EX:(shoesize>=8)}} and
25 {{EX:(sn=Richardson)}} is contained in {{EX:(sn=Richards*)}}
27 Correct matching rules and syntaxes are used while comparing
28 assertions for query containment. To simplify the query containment
29 problem, a list of cacheable "templates" (defined below) is specified
30 at configuration time. A query is cached or answered only if it
31 belongs to one of these templates. The entries corresponding to
32 cached queries are stored in the proxy cache local database while
33 its associated meta information (filter, scope, base, attributes)
34 is stored in main memory.
36 A template is a prototype for generating LDAP search requests.
37 Templates are described by a prototype search filter and a list of
38 attributes which are required in queries generated from the template.
39 The representation for prototype filter is similar to RFC 2254,
40 except that the assertion values are missing. Examples of prototype
41 filters are: (sn=),(&(sn=)(givenname=)) which are instantiated by
42 search filters (sn=Doe) and (&(sn=Doe)(givenname=John)) respectively.
44 The cache replacement policy removes the least recently used (LRU)
45 query and entries belonging to only that query. Queries are allowed
46 a maximum time to live (TTL) in the cache thus providing weak
47 consistency. A background task periodically checks the cache for
48 expired queries and removes them.
51 ({{URL:http://www.openldap.org/pub/kapurva/proxycaching.pdf}}) provides
52 design and implementation details.
55 H2: Proxy Cache Configuration
57 The cache configuration specific directives described below must
58 appear after a {{EX:overlay proxycache}} directive within a
59 {{EX:"database meta"}} or {{EX:database ldap}} section of
60 the server's {{slapd.conf}}(5) file.
62 H3: Setting cache parameters
64 > proxyCache <DB> <maxentries> <nattrsets> <entrylimit> <period>
66 This directive enables proxy caching and sets general cache parameters.
67 The <DB> parameter specifies which underlying database is to be
68 used to hold cached entries. It should be set to {{EX:bdb}},
69 {{EX:hdb}}, or {{EX:ldbm}}. The <maxentries> parameter specifies
70 the total number of entries which may be held in the cache. The
71 <nattrsets> parameter specifies the total number of attribute sets
72 (as specified by the {{EX:proxyAttrSet}} directive) that may be defined.
73 The <entrylimit> parameter specifies the maximum number of entries
74 in a cachable query. The <period> specifies the consistency
75 check period (in seconds). In each period, queries with expired
78 H3: Defining attribute sets
80 > proxyAttrset <index> <attrs...>
82 Used to associate a set of attributes to an index. Each attribute
83 set is associated with an index number from 0 to <numattrsets>-1.
84 These indices are used by the proxyTemplate directive to define
87 H3: Specifying cacheable templates
89 > proxyTemplate <prototype_string> <attrset_index> <TTL>
91 Specifies a cacheable template and the "time to live" (in sec) <TTL>
92 for queries belonging to the template. A template is described by
93 its prototype filter string and set of required attributes identified
99 An example {{slapd.conf}}(5) database section for a caching server
100 which proxies for the {{EX:"dc=example,dc=com"}} subtree held
101 at server {{EX:ldap.example.com}}.
104 > suffix "dc=example,dc=com"
105 > rootdn "dc=example,dc=com"
106 > uri ldap://ldap.example.com/dc=example%2cdc=com
108 > proxycache bdb 100000 1 1000 100
109 > proxyAttrset 0 mail postaladdress telephonenumber
110 > proxyTemplate (sn=) 0 3600
111 > proxyTemplate (&(sn=)(givenName=)) 0 3600
112 > proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600
115 > directory ./testrun/db.2.a
116 > index objectClass eq
117 > index cn,sn,uid,mail pres,eq,sub
120 H4: Cacheable Queries
122 A LDAP search query is cacheable when its filter matches one of the
123 templates as defined in the "proxyTemplate" statements and when it references
124 only the attributes specified in the corresponding attribute set.
125 In the example above the attribute set number 0 defines that only the
126 attributes: {{EX:mail postaladdress telephonenumber}} are cached for the following
131 > Filter: (&(sn=Richard*)(givenName=jack))
132 > Attrs: mail telephoneNumber
134 is cacheable, because it matches the template {{EX:(&(sn=)(givenName=))}} and its
135 attributes are contained in proxyAttrset 0.
137 > Filter: (&(sn=Richard*)(telephoneNumber))
140 is not cacheable, because the filter does not match the template,
141 nor is the attribute givenName stored in the cache
143 > Filter: (|(sn=Richard*)(givenName=jack))
144 > Attrs: mail telephoneNumber
146 is not cacheable, because the filter does not match the template ( logical
147 OR "|" condition instead of logical AND "&" )