1 / 26

Measurement and Analysis of LDAP Performance Xin Wang xwang@ctr.columbia

This study explores the performance of Lightweight Directory Access Protocol (LDAP) through tests and analysis. It covers the background of LDAP, experimental setup, test methodology, result analysis, related work, and conclusion addressing latency, throughput, and system components.

lhampton
Download Presentation

Measurement and Analysis of LDAP Performance Xin Wang xwang@ctr.columbia

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Measurement and Analysis of LDAP Performance Xin Wangxwang@ctr.columbia.edu ( Joint work with: Henning Schulzrinne, Dilip Kandlur, Dinesh Verma)

  2. Outline • Background • Experimental Setup • Test Methodology • Result Analysis • Related Work • Conclusion

  3. Background • What is LDAP? • A directory service is a simplified database, primarily for high volume read • LDAP: Lightweight Directory Access Protocols. • A client-server model, over TCP/IP • Tree structure: entry, attributes, values • Operations: add, delete, modify, compare, and search.

  4. Background (cont’d.) • LDAP for SLS Administration • Service level specification: type of service provided, and traffic constraints etc. • LDAP directory contains: SLS, policy rules, network provisioning information. • Decision entity: download classification rules, service specifications, and poll service periodically. • Enforcement entity: query rules from the decision entities

  5. LDAP Structure

  6. Experimental Setup • Hardware: • Server: dual processor Ultra-2, 200 MHz CPUs, 256 MB main memory • Clients: Ultra1, 170 MHz CPU, 128 MB main memory • 10 Mb/s Ethernet • LDAP server: • OpenLDAP 1.2 • LDBM backend: A high performance disk-based database • Berkeley DB 2.4.14, dbcachesize: 10 MB cachesize: vary

  7. Experimental Setup (cont’d) • LDAP Client

  8. Test Methodology • Search for downloading policy rules • Search filter: interface address, policy object. • Default size: entry 488 byte, directory 10,000 entries • Search operation: • ldap_search, ldap_bind, ldap_search, ldap_unbind.

  9. Measures • Latencies: • Connect: ldap_open + ldap_bind • Processing: ldap_search + data transmitting • Response: ldap_open -> ldap_unbind • Server throughput

  10. Result Analysis • Purpose: • identify system components on performance; suggest measure for improvement; study the performance limits, the determination component. • Overall LDAP performance • Improving Searching Performance • Performance Limitations • Session Reuse • Performance under Update Load

  11. Overall Performance

  12. Components of LDAP Search Latency

  13. Components of LDAP Connect Latency

  14. Effect of Nagle Algorithm

  15. Effect of Caching Entries

  16. Single vs. Dual Processor

  17. Single vs. Dual Processor

  18. Scaling of Directory Size

  19. Scaling of Directory Entry Size

  20. Scaling of Directory Entry Size

  21. Session Reuse

  22. Performance of Add Operation

  23. Related Work • Mindcraft • Netscape Directory Server 3.0 (NSD3) Netscape Directory Server 1.0 (NSD1) Novell LDAP services (NDS) • 10,000 entry personnel DB • Pentium Pro 200 MHz, 512 MB RAM • All experiments are in memory • Throughput • NSD3: 183 requests/second • NSD1: 38.4 requests/second • NDS: 0.8 requests/second • CPU is found to be the bottleneck

  24. Conclusion • General Results: • response latency 8 ms up to 105 requests/second • Maximum throughput 140 requests/second • 5 ms processing latency, and 36% from backend, 64 % from front end • Connect time dominate at high load, and limit the throughput • Disabling Nagle Algorithm • reduces about 50 ms • Entry Caching: • for 10,000 entry directory 10,000 entry caching, 40% improvement in processing time, 25% improvement in throughput

  25. Conclusion (cont’d) • Scaling of Directory Size: • In memory (10,000 -> 50,000), processing time increase 60%, throughput reduces 21%. • Out-o-f-memory (50,000 ->100,000), processing time increases another 87%, and throughput reduces 23%. • Scaling of Entry Size: • In-memory, mainly increase front-end processing, i.e., time for ASN.1 encoding . Increase processing time 8 ms, 88% due to ASN.1 encoding, and reduce throughput 30%. • Out-of-memory, reduce throughput 70%, mainly due to data transfer time.

  26. Conclusion (cont’d) • CPU: • In-memory, dual processors improves performance by 40%. • Session Re-use: • 60% improvement gain when session left open.

More Related