ghenry,

A quick Super Search resulted in node 304133, you may be interested in Old_Gray_Bear's reply, though it is not Open LDAP specific.

The Super Search also returned node 32196, which has links to benchmarking tools (along with other resources) in its replies.

The key phrase here being Super Search :)

Martin

When I benchmark LDAP servers, I usually use a monitor on a change detection mechanism rather than timing how long the modify/add/delete method in Net::LDAP blocks. That way (hopefully) you get the time before the modification hits the backend database, or something like it.

IMHO the best way is an asynchronous persistent search, but unfortunately AFAICT OpenLDAP doesn't support the persistent search control (it's alleged to be in recent dev releases, but I've never been able to find it). One way in OpenLDAP would be to enable replication in slapd.conf, and monitor the changelog file for the change you're after.

As you probably know, the speed of LDAP operations is very much dependent on (among other things) indices on the attributes involved. For that reason, you should document the attributes you're operating on, all the indices that relate to them, and (if you're using ACIs rather than the slapd.conf object security controls) any ACIs that relate to the operation. You should also document which database backend you're using, since OpenLDAP offers a choice.

I'd also recommend creating a fairly sizable (and reasonably deep) subtree to base your benchmarking on so that the database backend is being worked.

Watch out for caching as well - it'd be worth benchmarking 2 searches on the same object in quick succession so that the second time the object is sat in cache rather than having to be pulled in from the database.