[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: OpenLDAP performance issue



--On Wednesday, April 30, 2003 9:30 AM -0400 Sarah Burke <sarah.burke@bridgewatersystems.com> wrote:

This is my setup. I am running Openldap 2.1.6 on a Sun Ultra 60, dual
CPU. I configured the software with the "null" backend. This means that
no query is actually being performed, the server just errors back. I'm
using this case to see what kind of throughput I can get through the
OpenLDAP daemon iteself. I have changed nothing in the configure except
for enabling the null backend. I start up slapd, and I am using the
ldapsearch CLU to send a high load of requests to the server. I can only
get about 30 ldapsearch/ sec. Like I said before. Each ldapsearch
actually creates a new socket, bind, searches and unbinds. When I look at
the slapd process using "top", the process seems to be in sleep state 99%
of the time, even under heavy load??? Anyone know what is going on???
Thanks, Sarah ps. I will try this test with the lastest OpenLDAP version.


Sarah,

This really won't give you any meaningful performance numbers. Your rate of performance will vary based on many different factors, a large part of which is the DB backend you use, your DB cache size, your indexing, etc etc. The method that you use to query the server can also affect your results. I can tell you from my own performance testing of our setup, that the ldapsearch binary is a particularly inefficient way to test performance. With the ldapsearch binary, running queries from inside a perl script from multiple machines, we get approximately 66 queries/second. Using Net::LDAPapi from Cymas, with a single connection that performs multiple queries, I get from 220 to 400 queries/second, depending on how I structure my search. Using pooled connections can also greatly increase your search rate. Basically, what you are doing gives you no indication as to whether or not you will have the query rate you desire because there are so many other factors that influence what your actual query rate will be.

--Quanah

--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html