I am testing a bit with bind's. With consecutive binds with the same test account I always get 'result not in cache'. How can I get this in cache?
access_allowed: result not in cache (userPassword)
6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND dn="uid=test,dc=me,dc=local" method=128 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache (userPassword) 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to "uid=test,dc=me,dc=local " "userPassword" requested 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth access granted to "(anonymous)" 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by read(=rscxd)
Am 24.04.24 um 12:40 schrieb Marc:
I am testing a bit with bind's. With consecutive binds with the same test account I always get 'result not in cache'. How can I get this in cache?
access_allowed: result not in cache (userPassword)
6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND dn="uid=test,dc=me,dc=local" method=128 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache (userPassword) 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to "uid=test,dc=me,dc=local " "userPassword" requested 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth access granted to "(anonymous)" 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by read(=rscxd)
I think you need to index the userPassword attribute. For that you need to add the appropriate olcDBIndex entry to your database configuration.
https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directives
I am testing a bit with bind's. With consecutive binds with the same
test account I always get 'result not in cache'. How can I get this in cache?
access_allowed: result not in cache (userPassword)
6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
dn="uid=test,dc=me,dc=local" method=128
6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache
(userPassword)
6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
"uid=test,dc=me,dc=local " "userPassword" requested
6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
default auth access granted to "(anonymous)"
6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted
by read(=rscxd)
I think you need to index the userPassword attribute. For that you need to add the appropriate olcDBIndex entry to your database configuration.
https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv es
After doing this :
mv slapd.ldif slapd.ldif.bak
adding to the mdb section in slapd.conf index userPassword pres,eq
/etc/openldap # slapindex userPassword /etc/openldap # echo $? 0
I am still getting this access_allowed: result not in cache (userPassword)
I am testing a bit with bind's. With consecutive binds with the same
test account I always get 'result not in cache'. How can I get this in cache?
access_allowed: result not in cache (userPassword)
6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
dn="uid=test,dc=me,dc=local" method=128
6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in
cache
(userPassword)
6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
"uid=test,dc=me,dc=local " "userPassword" requested
6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
default auth access granted to "(anonymous)"
6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access
granted
by read(=rscxd)
I think you need to index the userPassword attribute. For that you need to add the appropriate olcDBIndex entry to your database configuration.
https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv
es
After doing this :
mv slapd.ldif slapd.ldif.bak
adding to the mdb section in slapd.conf index userPassword pres,eq
/etc/openldap # slapindex userPassword /etc/openldap # echo $? 0
I am still getting this access_allowed: result not in cache (userPassword)
Or is this related to adding openldap-overlay-proxycache ?
I am testing a bit with bind's. With consecutive binds with the
same
test account I always get 'result not in cache'. How can I get this
in
cache?
access_allowed: result not in cache (userPassword)
6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
dn="uid=test,dc=me,dc=local" method=128
6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in
cache
(userPassword)
6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
"uid=test,dc=me,dc=local " "userPassword" requested
6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
default auth access granted to "(anonymous)"
6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access
granted
by read(=rscxd)
I think you need to index the userPassword attribute. For that you
need
to add the appropriate olcDBIndex entry to your database configuration.
https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv
es
After doing this :
mv slapd.ldif slapd.ldif.bak
adding to the mdb section in slapd.conf index userPassword pres,eq
/etc/openldap # slapindex userPassword /etc/openldap # echo $? 0
I am still getting this access_allowed: result not in cache (userPassword)
Or is this related to adding openldap-overlay-proxycache ?
Am just testing with an alpine linux container and an ldap db with ~10 entries, almost nothing. Yet when I look in top res memory is 700MB. So I assume everything is already cached, but I don't really get then this logging. I don't even get why 700MB is being used, my data is probably a few 100KB.
--On Wednesday, April 24, 2024 8:37 PM +0000 Marc Marc@f1-outsourcing.eu wrote:
Am just testing with an alpine linux container and an ldap db with ~10 entries, almost nothing. Yet when I look in top res memory is 700MB. So I assume everything is already cached, but I don't really get then this logging. I don't even get why 700MB is being used, my data is probably a few 100KB.
It's the ACL cache, which is internal and you have no control over.
You've provided virtually no information on your environment's configuration for slapd. I would note that if you're seeing "result not in cache" then you have your logging level turned up insanely high on the server, which will slow down everything.
--Quanah
Am just testing with an alpine linux container and an ldap db with ~10 entries, almost nothing. Yet when I look in top res memory is 700MB. So
I
assume everything is already cached, but I don't really get then this logging. I don't even get why 700MB is being used, my data is probably
few 100KB.
It's the ACL cache, which is internal and you have no control over.
oh ok that makes sense.
You've provided virtually no information on your environment's configuration for slapd. I would note that if you're seeing "result not in cache" then you have your logging level turned up insanely high on the server, which will slow down everything.
I am just testing if some application is efficiently authenticating with a simple bind (and not doing searches) In a later stage I would like to maybe optimize authenticating against ldap with credential caching. When I saw this I just thought I could do something with it. (In another thread I posted about having binds max out at 150req/s, while searches are ~9000req/s)
--On Thursday, April 25, 2024 8:24 AM +0000 Marc Marc@f1-outsourcing.eu wrote:
I am just testing if some application is efficiently authenticating with a simple bind (and not doing searches) In a later stage I would like to maybe optimize authenticating against ldap with credential caching. When I saw this I just thought I could do something with it. (In another thread I posted about having binds max out at 150req/s, while searches are ~9000req/s)
Again, you've failed to provide any useful information about your setup, along with using an ldap benchmarking tool I've never heard of, so it's difficult to really draw any conclusions. Binds are always going to be slower than other operations since they involve things such as TLS (if used), DNS, and other items. Well written LDAP clients bind, and then use a persistent connection to do their operations.
As far as ldctl, as best I can tell, it's a single host based benchmark system, which is generally not a valid way to benchmark LDAP, since clients are generally distributed. In the past I've been trivially able to overwhelm the client's ability to do networking with tools like that. Valid LDAP benchmarking tools are distributed in nature (slamd, jmeter, etc) which better reflect real world traffic patterns.
--Quanah
openldap-technical@openldap.org
-
Marc -
Quanah Gibson-Mount -
Uwe Sauter