Open Source Solution Technology Corporation HAMANO Tsukasa <hamano@osstech.co.jp> LDAPCon 2015 Edinburgh November 2015
Abstract
This paper introduces WiredTiger backend for OpenLDAP. WiredTiger is an embedded database having characteristics of multi-core scalability and lock-free  algorithms. We implemented a new OpenLDAP backend called back-wt that is using WiredTiger database and then measured the per- formance.
1
Motivation
BerkeleyDB is a legacy embedded database.  The write performance of back-bdb (OpenLDAP back- end using BerkeleyDB) is painfully slow and not scalable.  If we flush disk asynchronously in order to improve the write performance, data durability will be sacrificed.  Although OpenLDAP is a multi- threaded application, the existing backends don't scale well with number of CPUs. The WiredTiger backend will bring about highly concurrent write performance.
2
Data Structure
First, we had to choose data structure either plain structure such as back-bdb or hierarchical struc- ture such as back-hdb.  If we choose the plain structure, sub scope searching is fast but modrdn and add operations need extra cost.  Actually we can't use modrdn with sub directories on back-bdb. The plain structure need many @ prefix entries for sub scope searching, and also % prefix entries are needed for one scope searching.  If we choose the hierarchical structure, modrdn is fast but lookup and sub scope search need extra cost. Figure 1: Plain structure vs Hierarchical structure We followed basically plain data structure but we made some enhancements to the data struc- ture for performance and database footprint.  Be- fore adding an entry, we reverse the DN per RDN and then add the Reverse DN as the key into WiredTiger's B-Tree table.  At this point, entries are sorted by Reverse DN , so we can search rapidly with a sub scope using WiredTiger's range search. The range search is an efficient method that only needs WT_CURSOR::search_near() and increment cursor operations for this purpose. 1 cn=hamano,ou=Users, dc=com,dc=example,ou=users,cn=hamano Figure 2: Making Reverse DN
Data Durability
3
WiredTiger has several durability levels of trans- action.  Here is the back-wt settings correspond- ing to each durability level.  In back-wt, we can set wtconfig patameter in order to set dura- bility level.  This parameters are just passed to wiredtiger_open(). 1. Write transaction log into memory. This is the fastest, but it only ensure durability at check- point.
wtconfig log=(enabled=false)
Listing 1: slapd.conf for in-memory transaction log 2. Write transaction log into file, but log records aren't flushd for each commit of the transac- tion.  This is equivalent to dbnosync in back- bdb. wtconfig log=(enabled) wtconfig transaction_sync=(enabled=false) Listing 2:  slapd.conf  for  writing  transaction  log without sync 3. Write transaction log into file, and log records are flushd for each commit of the transaction. wtconfig log=(enabled) wtconfig transaction_sync=(enabled=true) Listing 3:  slapd.conf for writing transaction log with sync 4
Current Status
● slapadd, slapcat, slapindex have been imple- mented. ● basic LDAP operations (BIND, ADD, DELETE, SEARCH, MODIFY, MODRDN) have been implemented. ●  Password  Modify  Extended  Operation (RFC) 3062) works. ● deref search has not been implemented yet. ● alias and glue entry have not been imple- mented yet. ● WiredTiger does not support multiprocess ac- cess yet.  It means that we can't do slapcat while running slapd at the moment. However, WiredTiger is planning to support RPC in the future. If it is realized, we can do hot-backup while avoiding multi-process locking. ● We do not implement entry cache similar to back-bdb. It's not absolutely necessary since WiredTiger cache is fast enough. ●  back-wt currently uses B-Tree table.  We will test LSM table in the future. S
Benchmarking
We have measured benchmarks that focus on con- currency performance by new benchmarking tool
that called lb. 1  This benchmark tool can generate many concurrency load by goroutines of Go.  See our wiki page for detail of benchmarks. 2 5.1
Enviroments
We have executed benchmarks on following envi- ronments: ● 12 Core x 2 Hyper Threading = 24 Logical CPUs. ● 15,000 RPM SAS Disks, not used RAID cards. ● Database directory was placed on ext4 file system on Linux box. ●  60G Memory ● OpenLDAP of git master at Sep 2015 and ap- plied some back-wt patches. ● No checkpoint was performed during the benchmarking. ● We measured two methods for ADD bench- marking, the first flushes disk transaction log each request and the second doesn’t flush disk transaction log each request.
Results
5.2
¹https://github.com/hamano/lb ²https://github.com/osstech-jp/openldap/wiki/
Analysis
5.3
● We have only used 24 logical CPUs. We may get more scalability on more CPUs. ● The reading performances are much the same. ● The concurrency writing performances of back-wt are pretty good.