1 / 29

Xin Wang Internet Real -Time Laboratory Columbia University

Measurement and Analysis. of LDAP Performance. Xin Wang Internet Real -Time Laboratory Columbia University ( Joint work with Henning Schulzrinne, Dilip Kandlur, and Dinesh Verma ) http://www.cs.columbia.edu/~xinwang. Outline. Introduction to LDAP

grace
Download Presentation

Xin Wang Internet Real -Time Laboratory Columbia University

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 Wang Internet Real -Time Laboratory Columbia University (Joint work with Henning Schulzrinne, Dilip Kandlur, and Dinesh Verma) http://www.cs.columbia.edu/~xinwang

  2. Outline • Introduction to LDAP • Motivation • Background • Experimental Setup • Test Methodology • Result Analysis • Related Work • Conclusion

  3. What is LDAP? • Directory Service • A simplified database, primarily for high volume efficient reads; no database mechanisms to support roll-back of transactions • LDAP: Lightweight Directory Access Protocol • A distributed client-server model over TCP/IP • Can access stand-alone directory servers or X.500 directories

  4. Motivation • Wide use of LDAP • personnel databases for administration, tracking schedules, address translation for IP telephony, storage of network configuration, etc. • Performance ofLDAP? • relatively static data, caching to improve performance • Can LDAP be used in a dynamic environment with frequent searches?

  5. Background: LDAP Structure • Tree structure: entry, attributes, values • Operations: add, delete, modify, compare, and search.

  6. Background (cont’d.) • LDAP for SLSAdministration • A better than best effort service, e.g., int-serv, diff-serv, requires a service level specification (SLS) between the network and customer • SLS specifies type of service, user traffic constraints, quality expected, etc. May be dynamically negotiated • LDAP directory contains: SLS, policy rules, network provisioning information

  7. LDAP Structure for SLS Management • Management tools are used to populate and maintain LDAP directory • Decision entities download classification rules, service specifications, and poll directory periodically. • Enforcement entities query rules from the decision entities and enforce them

  8. LDAP Tree Structure in the Experiments

  9. Experimental Setup • Hardware: • Server: dual Ultra-2 processors, 200 MHz CPUs, 256 MB main memory; server was bound to one of the CPUs. • Clients: Ultra1, 170 MHz CPU, 128 MB main memory • 10 Mb/s Ethernet • LDAP server: • OpenLDAP 1.2, Berkeley DB 2.4.14 • Stand -alone LDAP daemon (slapd) : front end handling communication with LDAP clients, and backend handling database operations. • LDBM backend: a high performance disk-based database • cachesize: size in entries of in-memory cache; variable size • dbcachesize: size in bytes of the in-memory cache associated with each open index file; 10 MB

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

  11. Test Methodology • Search is likely to dominate the server operations, mainly test search performance for downloading policy rules • Search filter: interface address, and corresponding policy object • Default parameters: • Directory size: 10,000 entries • Entry size: 488 bytes • Search operation steps: • ldap_open, ldap_bind, ldap_search, ldap_unbind

  12. Search Sequences

  13. Performance Measures and Objectives • Latencies: • Connect: ldap_open + ldap_bind • Processing: ldap_search + result transmission • Response: ldap_open -> ldap_unbind (~connect+processing) • Server throughput: requests served per second • Objectives: use latencies and throughput to evaluate • Overall LDAP performance • Effect of individual system components on performance • System scalability and performance limits • Performance under update load • Measures to improve system performance

  14. Overall Performance Average connection time, processing time, and response time Average server throughput

  15. Components of LDAP Search Latency Client Server

  16. Components of LDAP Connect Latency

  17. Effect of Nagle Algorithm Average server connection , processing, and response time Average server throughput

  18. Effect of Caching Entries Average connection, processing , and response time with 10,000 entry cache and without cache Average server throughput

  19. Single vs. Dual Processor Average server throughput Average server connection, processing, and response time

  20. Single vs. Dual Processor (cont’d) Read and write throughput

  21. Scaling of Directory Size a)10,000 entries in DB, 10,000 in cache; b) 50,000 DB, 50,000 cache; c)100,000 DB, 50,000 cache Average connection and processing time Average server throughput

  22. Scaling of Directory Entry Size (in-memory) (488 bytes vs. 4880 bytes) Average connection and processing time Average server throughput

  23. Scaling of Directory Entry Size (out-of-memory) (488 bytes vs. 4880 bytes) Average server connection time and processing time Average server throughput

  24. Connection Reuse (no reuse, 25 % reuse, 50% reuse, 75% reuse, 100% reuse) Average server processing time Average server throughput

  25. Latency and Throughput for Search and Add Average server connect, processing, and response time Average server throughput

  26. 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

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

  28. Conclusion (cont’d) • Scaling with Directory Size - determined by back-end processing • In memory operation, 10,000 -> 50,000: processing time increases 60%, throughput reduces 21%. • Out-of-memory, 50,000 ->100,000: processing time increases another 87%, and throughput reduces 23%. • Scaling with Entry Size (488 ->4880 bytes): • In-memory, mainly increase in front-end processing, i.e., time for ASN.1 encoding . Processing time increases 8 ms, 88% due to ASN.1 encoding, and throughput reduces 30%. • Out-of-memory, throughput reduces 70%, mainly due to increased data transfer time.

  29. Conclusion (cont’d) • CPU: • During in-memory operation, dual processors improve performance by 40%. • Connection Re-use: • 60% performance gain when connection left open.

More Related