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 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
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:
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
oh ok that makes sense.
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:
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