When I benchmark writes to 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 worth trying in OpenLDAP would be to enable replication in slapd.conf, and monitor the changelog file for the change you're after. That approach also adapts easily for benchmarking replication speeds.
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.
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
Can you spare 2 minutes to help with my research? If so, please click here
| [reply] |
| [reply] |
| [reply] |