On 2017-02-03 20:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I am wondering if this is as good as it gets or if there are other things to tweak or to try, to get a shorter timeout in this
well, you've set those values to 2 and 2 - so 4 is what you should expect.... what is the time taken to do a query when the server is working? you might be able to do a 1s per value, you should also look at using caching etc to ensure that you hit the LDAP as few times as possible
Actually, looking at the log shows the LDAP module is timing out and reconnecting once after 2 seconds (options.res_timeout), retrying, timing out again after 2 seconds, reconnecting and failing the request. This pattern is apparently affected by pool.start, but despite setting that to 0 I could not get it to skip the first reconnect+retry. I wouldn't want to further reduce options.res_timeout in fear of hitting some "false positive" timeouts. Thanks for suggesting caching, maybe that could help at least reduce the latency for some subsequent re-authentications.
you have a bad LDAP - what is the issue - why cant it be fixed rather than putting sticking plasters on rest of intrastrucure... your logs already show a NAS resending
Yep, it's a mess.
when no just run a slave OpenLDAP server locally to keep the values you need on hand and quick?
The second backend is (sort of) a partial replica (no password attributes). We can do better than that, for sure. Thanks, Z.