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

Re: ACL optimization



"José M. Fandiño" wrote:
> 
> Quanah Gibson-Mount wrote:
> > > As a curiosity, servers matched by the first rules are about 5 or 6 times
> > > faster to response than servers matched by last rules. I thought that
> > > the ACL evaluation time will be uniform because the whole set of rules
> > > would be evaluated. this makes sense to someone?
> 
> ...
> 
> > The one other thing I noticed about your configuration is that you had a
> > 9.5MB BDB cache. This may or may not really be sufficient.  You have a
> > small number of entries, but you also have a large number of attributes per
> > entry, and if you have extensive indexing, that would also be a factor.
> 
> Quanah, I don't know if it makes some difference but 125 is the theorical
> number of attributes (it is the raw number of attributes for the set of
> objectclasses I use), the real number of attributes used by entries is
> 50 approx.
> 
> > I'd be curious if you'd get a performance increase with a larger BDB cache
> > size (say 100MB, where you would have set_cachesize 0 104857600 0) and see
> > if that improved your results.
> 
> with 100MB the response times are almost identical, of course this time
> I have reconstructed the bdb database (slapcat, rm, slapadd)
> 
> please remember I do a heavy use of break controls in the who part of the
> rules (100 x 2 = 200 rules).
> 
> these are the times (tests were done in idle machines):
> 
> # time ldapsearch -b ou=personas,ou=cuentas,dc=domain -s sub -D cn=... -w ... -x  > /dev/null
> real    0m1.482s
> user    0m0.110s
> sys     0m0.000s
> 
> # time ldapsearch -b ou=personas,ou=cuentas,dc=domain -s sub -D cn=... -w .. -x  > /dev/null
> real    0m1.405s
> user    0m0.070s
> sys     0m0.000s
> 
> the second time is lower because of caching. In this test the matched identity
> for the server was located last in the ACL and in the next the server identity
> was first in the list:
> 
> # time ldapsearch -b ou=personas,ou=cuentas,dc=domain -s sub -D cn=... -w ... -x  > /dev/null
> real    0m0.191s
> user    0m0.080s
> sys     0m0.000s
> 
> # time ldapsearch -b ou=personas,ou=cuentas,dc=domain -s sub -D cn=... -w ... -x  > /dev/null
> real    0m0.132s
> user    0m0.090s
> sys     0m0.010s
> 
> as you can see there is a big difference.
> 
> I can understand that this setup is cpu intensive, but I still can't
> understand why the order is so important.

hhmm,  might it be that the OpenLDAP daemon gives a response as
soon as it has data available to return?

if this is true I should see cpu consumption until 1.482 - 0.191 seconds
later and the total time whould be always 1.482ms (approx.)

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w---
O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++
G++ e- h+(++) !r !z
------END GEEK CODE BLOCK------