On Wed, 17 May 2017, Roger Szabo wrote:
The goal is to perform frequent periodic calls to check the health of OpenLDAP using anonymous bind.
Someone at http://stackoverflow.com/questions/16077473/ldap-bind-vs- suggested that a ldapcompare would perform better than a ldapsearch because "there is only a single response per entry (a compare result) rather than two (a search result entry and a search result done)".search
This explanation makes sense but it would be really great to hear the opinion of an expert on this, thank you very much :)
Overall, seems a bit oversimplified. I suppose the common case compare would typically be cheaper than a search, but you could just as easily be comparing against some dynamic membership where the matching is expensive, potentially invoking multiple internal searches (there goes your savings). On the other hand, if the search requires access to unindexed data, maybe the search is more expensive. If the result set is large, maybe the search is more expensive even if it is indexed!
But you're talking about health, so the entire conversation may need to be reframed. There's nothing in the RFC that says you have to search nor compare. You could do something definitely in-core, i.e. ldapwhoami(1) ... or a simple "can I speak the protocol properly?" could be connect, BIND, UNBIND, close.
As with most things, you'd have to think through your precise cases and plan accordingly. If you're only concerned with general health of slapd(8), a back-null or back-monitor would both be fairly cheap (back-null literally being as cheap as it gets). But it IS possible to have backend(s) fail while the slapd(8) frontend remains operational, so monitoring of individual backends may be warranted too. (This is my practice -- each backend gets an indexed monitoring search, with a search congruent with the common use case for each backend.)
The counterargument to all of this, across any network service, is "if your monitoring strains your capacity limits you're probably running too hot anyway."