[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: OpenLDAP performance issue
My issue, is that I want to use OpenLDAP as the LDAP front end of an
application.
This application will have many different clients, that will connect each
time they perform an LDAP search.
More similar to a web server, then a typical LDAP directory.
So it doesn't make sense in my case, to connect once, and then do multiple
searches on the same connection.
When I do this, I do see performance improve greatly!
So has anyone ever tried to do this with OpenLDAP?
Performance seems to degrade greatly when multiple clients are continuously
trying to connect?
Any help or info appreciated!
Sarah
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]
Sent: Wednesday, April 30, 2003 10:17 AM
To: openldap-software@OpenLDAP.org
Subject: 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
Bridgewater Systems Hosts a 4-city Wi-Fi Forum for Service Providers May 7-14, 2003
To learn more about the event and to register please visit: http://www.bridgewatersystems.com/forum