RE: cache userPassword with bind

2024-04-25 Thread Quanah Gibson-Mount




--On Thursday, April 25, 2024 8:24 AM + Marc  
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



RE: cache userPassword with bind

2024-04-25 Thread Marc
> 
> > 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)