I am testing an OpenLDAP server with 3000 fake 'people' entries, but it does not perform as well as I would expect. I have added some tweaks based on my research of the documentation. Is there anything I am missing here? Is there any way to further tune this setup?
I have written a script to test the directory. It is written in PHP using the standard LDAP libraries. Both the script, and the LDAP server are running on the same box. The script is calling the server via the public interface (not the loopback) using standard port 80. It basically does a search on a matching query. The search query was "sn=BE*". Below is the info for my setup:
Linux Debian etch system
OpenLDAP version: # /usr/sbin/slapd -V @(#) $OpenLDAP: slapd 2.3.30 (Mar 9 2007 05:43:02) $
Here are my additions to the slapd.conf file (other than these, the file is essentially like the default):
. . . . TLSCipherSuite HIGH TLSCACertificateFile /etc/ldap/demoCA/cacert.pem TLSCertificateFile /etc/ldap/newcert.pem TLSCertificateKeyFile /etc/ldap/newreq.pem TLS_REQCERT never
############################################### # Performance tweaks added by me -JLP
index sn subinitial
cachesize 100000 dbcachesize 1000000
# Tells openldap how many threads to use # more does not necessarily mean better performance unless you have multiple cpus threads 8
# Tells slapd to close connections that have been idle for 30 seconds or more. idletimeout 30
# Tells slapd to store the 20,000 most used IDL's frequented when accessing entries in memory. idlcachesize 20000 EOF
tia,
Jason
--On Thursday, July 05, 2007 3:57 PM -0400 Jason Peters jlpeters@ispalliance.net wrote:
I am testing an OpenLDAP server with 3000 fake 'people' entries, but it does not perform as well as I would expect. I have added some tweaks based on my research of the documentation. Is there anything I am missing here? Is there any way to further tune this setup?
I have written a script to test the directory. It is written in PHP using the standard LDAP libraries. Both the script, and the LDAP server are running on the same box. The script is calling the server via the public interface (not the loopback) using standard port 80. It basically does a search on a matching query. The search query was "sn=BE*". Below is the info for my setup:
LDAP uses port 389, not 80. Sounds like you are testing a web server?
Linux Debian etch system
OpenLDAP version: # /usr/sbin/slapd -V @(#) $OpenLDAP: slapd 2.3.30 (Mar 9 2007 05:43:02) $
Here are my additions to the slapd.conf file (other than these, the file is essentially like the default):
############################################### # Performance tweaks added by me -JLP
index sn subinitial
What database backend are you using? ldbm? dbcachesize is not a parameter for back-bdb/hdb.
cachesize 100000 dbcachesize 1000000
You really don't provide enough information to help.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Yes, ultimately this will be used in a web-based application, and that's why we are using a cgi script to test. Is this a bad idea? should I be directly testing the OpenLDAP server?
It is using back_bdb. I have removed the dbcachesize parameter.
Quanah Gibson-Mount wrote:
--On Thursday, July 05, 2007 3:57 PM -0400 Jason Peters jlpeters@ispalliance.net wrote:
I am testing an OpenLDAP server with 3000 fake 'people' entries, but it does not perform as well as I would expect. I have added some tweaks based on my research of the documentation. Is there anything I am missing here? Is there any way to further tune this setup?
I have written a script to test the directory. It is written in PHP using the standard LDAP libraries. Both the script, and the LDAP server are running on the same box. The script is calling the server via the public interface (not the loopback) using standard port 80. It basically does a search on a matching query. The search query was "sn=BE*". Below is the info for my setup:
LDAP uses port 389, not 80. Sounds like you are testing a web server?
Linux Debian etch system
OpenLDAP version: # /usr/sbin/slapd -V @(#) $OpenLDAP: slapd 2.3.30 (Mar 9 2007 05:43:02) $
Here are my additions to the slapd.conf file (other than these, the file is essentially like the default):
############################################### # Performance tweaks added by me -JLP
index sn subinitial
What database backend are you using? ldbm? dbcachesize is not a parameter for back-bdb/hdb.
cachesize 100000 dbcachesize 1000000
You really don't provide enough information to help.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Thursday, July 05, 2007 4:32 PM -0400 Jason Peters jlpeters@ispalliance.net wrote:
Yes, ultimately this will be used in a web-based application, and that's why we are using a cgi script to test. Is this a bad idea? should I be directly testing the OpenLDAP server?
If you want to know how the *ldap* server is performing, then yes, you need to test the LDAP server. Then work on testing via the web.
It is using back_bdb. I have removed the dbcachesize parameter.
I suggest reading the OpenLDAP FAQ on tuning DB_CONFIG for BDB.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
<quote who="Quanah Gibson-Mount">
--On Thursday, July 05, 2007 4:32 PM -0400 Jason Peters jlpeters@ispalliance.net wrote:
Yes, ultimately this will be used in a web-based application, and that's why we are using a cgi script to test. Is this a bad idea? should I be directly testing the OpenLDAP server?
If you want to know how the *ldap* server is performing, then yes, you need to test the LDAP server. Then work on testing via the web.
It is using back_bdb. I have removed the dbcachesize parameter.
I suggest reading the OpenLDAP FAQ on tuning DB_CONFIG for BDB.
http://www.openldap.org/faq/data/cache/190.html
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Jason Peters jlpeters@ispalliance.net writes:
I am testing an OpenLDAP server with 3000 fake 'people' entries, but it does not perform as well as I would expect. I have added some tweaks based on my research of the documentation. Is there anything I am missing here? Is there any way to further tune this setup?
What do you expect?
$ time ldapsearch -Y external -H ldapi:/// \ -b ou=benchmark,o=avci,c=de -s one sn=* ...
# numResponses: 9001 # numEntries: 9000
real 0m18.959s user 0m0.231s sys 0m0.096s
The total number of entries is some 30K
What are your results?
-Dieter
openldap-software@openldap.org