The largest consumer of directory information at Stanford is the mail routing system. It therefore drove our basic performance requirements for the new Directory service. The basic requirement that we arrived at was 45 queries/second across the pool of servers dedicted to mail (however many that needed to be).
How we test performance of the servers
To test the performance of the servers, we set up a simple shell script that used ldapsearch to run queries against a single replica. The script would authenticate via a SASL/GSSAPI bind to the replica as the calling user, so it needed to be ran by an individual with appropriate access rights. We then set up the script to be run from multiple machines, mirroring the requests that the mailrouters would use. This would be a search on our account subtree, filtering on "uid" and returning "sumaildrop". To load the uid pool, we read in a file containing both active and inactive accounts, to simulate the types of mail that comes through our routers every day.
System setup
- OpenSSL: 0.9.6g
- Kerberos: MIT krb5-1.2.1
- Cyrus-SASL: cyrus-sasl-2.1.9
- BDB: db4-4.1.24
- OpenLDAP: 2.1.8
- OS: Solaris 8
Performance results
The initial results of our performance tests were horrific. After a short time of running queries, the slapd process running on the replica would lock up completely. Not only that, we were seeing an query rate that averaged at 3-4 queries/second. This meant we'd need approximately 10 machines to just to meet our performance requirements! Obviously alarmed, we tried a variety of different tests to see if we could increase performance and stop having the slapd process lock up on us.
Those included:
- Changing the loglevel from high to low
- Changing the memory cache options
- Using a different ldapsearch binary
- Using anonymous binds
- Using -LLL to quiety the ldapsearch output
- Changing the OS to Solaris 9
