BGRP: (Border Gateway Reservation Protocol) A Tree-Based Aggregation Protocol for Inter-Domain Reservations

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 of LDAP?
• 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 (contd.)

• LDAP for SLS Administration
• 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 (contd)

• 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 -gt ldap_unbind
  (connectprocessing)
• 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 (contd)
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 server throughput
Average connection and processing time
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 throughput
Average server processing time
25
Latency and Throughput for Search and Add
Average server throughput
Average server connect, processing, and response
time
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 (contd)

• Scaling with Directory Size - determined by
  back-end processing
• In memory operation, 10,000 -gt 50,000 processing
  time increases 60, throughput reduces 21.
• Out-of-memory, 50,000 -gt100,000 processing time
  increases another 87, and throughput reduces
  23.
• Scaling with Entry Size (488 -gt4880 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 (contd)

• CPU
• During in-memory operation, dual processors
  improve performance by 40.
• Connection Re-use
• 60 performance gain when connection left open.