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

Casual benchmarking OS performace with OpenLDAP

I'm in the process of trying to find the best OS platform on which to run
OpenLDAP as a backend for Heimdal and Samba, as well as a replacement for

Currently, I have a machine with a 2.8GHz Xeon and a 140G drive which 
holds both Debian Linux (kernel 2.6.11) and Solaris 10 x86 .

Here is the pertinent server info:

        OpenLDAP 2.3.2beta  (gcc -O2)
        DB 4.2.52 w patches (Debian default)

    Solaris x86:
        OpenLDAP 2.3.2beta  (SUNWspro/cc -xO4)
        DB 4.2.52 w patches (SUNWspro/cc -xO4)

I'm using a simple test of running 10 ldapsearch processes like so:

    for i in 0 1 2 3 4 5 6 7 8 9 ; do
        time ldapsearch -H ldap://server.cise.ufl.edu -x > /dev/null &

My client machine is a solaris x86 box with a couple of 2.8GHz Xeon

My LDAP database has 8421 records. Here are some sample entries of
ou=Users, ou=Groups, and ou=Netgroups:

    dn: uid=nobody,ou=Users,dc=test,dc=org
    cn: nobody
    sn: nobody
    objectClass: inetOrgPerson
    objectClass: sambaSamAccount
    objectClass: posixAccount
    gidNumber: 514
    uid: nobody
    uidNumber: 65534
    homeDirectory: /dev/null
    sambaPwdLastSet: 0
    sambaLogonTime: 0
    sambaLogoffTime: 2147483647
    sambaKickoffTime: 2147483647
    sambaPwdCanChange: 0
    sambaPwdMustChange: 2147483647
    sambaHomePath: \\server\nobody
    sambaHomeDrive: H:
    sambaProfilePath: \\server\profiles\nobody
    sambaSID: S-1-5-21-0000-0000-0000-501
    sambaPrimaryGroupSID: S-1-5-21-0000-0000-0000-514
    sambaAcctFlags: [NU         ]
    loginShell: /bin/false

    dn: cn=operator,ou=Groups,dc=test,dc=org
    objectClass: posixGroup
    objectClass: top
    objectClass: sambaGroupMapping
    cn: operator
    gidNumber: 10
    sambaSID: S-1-5-21-0000-0000-0000-200009
    sambaGroupType: 5
    memberUid: user1
    memberUid: user2
    memberUid: user3
    memberUid: user4
    memberUid: user5
    memberUid: user6
    memberUid: user7
    memberUid: user8
    memberUid: user9
    memberUid: user10
    dn: cn=operator,ou=Netgroups,dc=test,dc=org
    objectClass: top
    objectClass: nisNetgroup
    cn: operator
    nisNetgroupTriple: (-,user1,domain)
    nisNetgroupTriple: (-,user2,domain)
    nisNetgroupTriple: (-,user3,domain)
    nisNetgroupTriple: (-,user4,domain)
    nisNetgroupTriple: (-,user5,domain)
    nisNetgroupTriple: (-,user6,domain)
    nisNetgroupTriple: (-,user7,domain)
    nisNetgroupTriple: (-,user8,domain)
    nisNetgroupTriple: (-,user9,domain)
    nisNetgroupTriple: (-,user10,domain)

  [ I did make a minor modification to the nis.schema. The PADL nss_ldap module had
    trouble querying the netgroups unless I changed the nisNetgroupTriple definition

    attributetype ( NAME 'nisNetgroupTriple'
        DESC 'Netgroup triple'
        SYNTAX )


    attributetype ( NAME 'nisNetgroupTriple'
        EQUALITY caseExactIA5Match
        SUBSTR caseExactIA5SubstringsMatch
        SYNTAX )


Here's the slapd.conf I'm using:

    include             /usr/local/etc/openldap/schema/core.schema
    include             /usr/local/etc/openldap/schema/cosine.schema
    include             /usr/local/etc/openldap/schema/inetorgperson.schema
    include             /usr/local/etc/openldap/schema/misc.schema
    include             /usr/local/etc/openldap/schema/nis.schema
    include             /usr/local/etc/openldap/schema/samba.schema
    include             /usr/local/etc/openldap/schema/krb5-kdc.schema
    allow bind_v2
    allow bind_anon_cred
    allow bind_anon_dn
    allow update_anon
    pidfile         /var/run/slapd.pid
    database        bdb
    directory       /var/ldap/db
    modulepath      /usr/local/libexec/openldap
    lastmod         on
    cachesize       100000
    sizelimit       unlimited
    idlcachesize    300000
    threads         20
    suffix          dc=test,dc=org
    rootdn          cn=ldapadmin,dc=test,dc=org
    rootpw          XXXXXXXXXXXXXX
    sasl_host   server.cise.ufl.edu
    sasl_realm  CISE.UFL.EDU
    index objectclass               eq
    index cn                        pres,sub,eq
    index sn                        pres,sub,eq
    index uid                       pres,sub,eq
    index displayName               pres,sub,eq
    index uidNumber                 eq
    index gidNumber                 eq
    index memberUid                 eq
    index   sambaSID                eq
    index   sambaPrimaryGroupSID    eq
    index   sambaDomainName         eq
    index   default                 sub
    index   nisNetgroupTriple       pres,sub,eq
    index   memberNisNetgroup       pres,eq,sub
    index   krb5PrincipalName       pres,eq
    TLSCACertificateFile    /usr/local/lib/ssl/certs/-cacert.pem
    TLSCertificateKeyFile   /usr/local/lib/ssl/certs/server.cise.ufl.edu-key.pem
    TLSCertificateFile      /usr/local/lib/ssl/certs/server.cise.ufl.edu-cert.pem
    sasl-regexp "uidNumber=0\\\+gidNumber=.*,cn=peercred,cn=external,cn=auth"
    sasl-regexp "uidNumber=0\\\+gidNumber=.*,cn=peercred,cn=external,cn=auth"
    access to dn=""
      by * read
    access to dn.base=""
      by * read
    access to *
            by dn="cn=ldapadmin,dc=test,dc=org" write
            by self write
            by * read
            by anonymous auth
    access to attr=supportedSASLMechanisms,subschemaSubentry
      by anonymous read
      by * read

Also, here's the DB_CONFIG:

    set_cachesize   0       104857600       1
    set_lg_regionmax        1048576
    set_lg_max              10485760
    set_lg_bsize            2097152
    set_flags               DB_TXN_NOSYNC

Note this is still a test server, so these are not necessarily the final
forms of the slapd.conf/DB_CONFIG . 

My results with this setup are suprising. A run of the 10 ldapsearch 
requests at a time yield the following (20 server threads):

    Linux       :      10 ldapsearches on (objectClass=*)  :   ~3:15
    Sol10x86    :      10 ldapsearches on (objectClass=*)  :   ~0:06.5

So the queries that take over 3 minutes on Linux take less that 7 seconds
on Solaris x86. 

Here are results for changing the number of threads:


    Threads     Shortest    Longest     Average
    8           2:07        3:19        2:34
    4           1:18        3:19        2:14
    2           (awful)

To my suprise, Solaris showed the same kinds of improvements with fewer threads,
bringing the shortest search time down to 2 1/2 seconds:

    Threads     Shortest    Longest     Average
    8           0:05.5      0:07        ~0:06
    4           0:02.5      0:06.7      ~0:04.6
    2           (didn't bother)

Ultimately, I'm interested in finding out why the Linux results are so 
much poorer -- I'm relatively new to OpenLDAP and want to make sure I'm 
not making any elementary mistakes before we go live with the new setup,
as it will be a Big Deal. 

Does anyone have any comments on this setup or these tests?


| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh@cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |