This document discusses factors that impact the performance of an LDAP server. It notes that memory access is much faster than accessing storage devices like SSDs or disks. It also discusses how the LDAP server handles search requests by normalizing filters, finding the appropriate backend, and selecting candidate entries. The use of indexes, caching, appropriate hardware, and network configuration can all help optimize performance.

1. What makes a LDAP server
running fast ?

2. Emmanuel Lécharny
Apache Software Foundation member
Chairman of MINA project
PMC of Apache Directory Project
IKTEK Owner (www.iktek.com)
www.iktek@com, elecharny@iktek.com

3. Latency numbers
every programmer should know !
(https://gist.github.com/hellerbarde/2843375)
Main memory reference ...................... 100 ns
Read 1 MB sequentially from memory ..... 250,000 ns
= 250 µs
Read 1 MB sequentially from SSD* ..... 1,000,000 ns
=
1 ms
Send 1 MB over 1 Gbps network ....... 10,000,000 ns
=
10 ms
Disk seek ........................... 10,000,000 ns
=
10 ms
Read 1 MB sequentially from disk .... 20,000,000 ns
=
20 ms
3

4. A request...

5. Search : From client to client

6. ASN/1

7. ASN/1 codec
FROM :
connection.bind( "uid=akarasulu,dc=example,dc=com", "password" );
TO :
0x30, 0x33,
0x02, 0x01, 0x01,
0x60, 0x2E,
// LDAPMessage ::=SEQUENCE {
// messageID MessageID
// CHOICE { ..., bindRequest BindRequest, ...
// BindRequest ::= APPLICATION[0] SEQUENCE {
0x02, 0x01, 0x03,
// version INTEGER (1..127),
0x04, 0x1F,
// name LDAPDN,
'u', 'i', 'd', '=', 'a', 'k', 'a', 'r', 'a', 's', 'u', 'l', 'u', ',', 'd', 'c', '=', 'e', 'x', 'a',
'm', 'p', 'l', 'e', ',', 'd', 'c', '=', 'c', 'o', 'm',
( byte ) 0x80, 0x08,
// authentication AuthenticationChoice
// AuthenticationChoice ::= CHOICE { simple [0] OCTET STRING,
// ...
'p', 'a', 's', 's', 'w', 'o', 'r', 'd'
7

8. Searching

9. Search, search, search
It's all about
Search
performance !

10. Check, please !

11. Search Request Checks
Checks done before the first entry is returned :
- Normalize the filter
- Check if the password should be reset
- Check if the user is authenticated
- Check the filter attributes
- Find the backend
This represents 9% of the initial
search processing
(for a search returning one entry).
11

12. The candidates

13. Selecting candidates
Candidates are references
to
entries
(in other words, they are just pointers...)

14. Selecting candidates
AND
OR
NOT
No index
∀
∀
∀
Index
∩
∪
∀
Remember : We don't actually fetch any entry !

15. Candidates & AND filter
Maximum = min(filters candidates)
Minimum = min(filters candidates)
Here, max = 72 and min = 72

16. Candidates & OR filter
Maximum = sum(filters candidates)
Minimum = sum(filters candidates)
Here, max = 8098 and min = 8098

17. Cost of creating candidates
Looking for the best index
+
Creating the set of references
=
20% of the search processing

18. Index
No index,
no
Gain

19. Filters
Build your search
Filters
with caution

20. The Cache

21. Cache
It's all about
Memory
Vs
Disk
latency

22. Reminder
Disk is from 4x to 80x slower !
Read 1 MB sequentially from memory ..... 250,000 ns
= 250 µs
Read 1 MB sequentially from SSD* ..... 1,000,000 ns
=
1 ms
Read 1 MB sequentially from disk .... 20,000,000 ns
=
20 ms

23. Cache, the good
No Disk access
=>
Fast (very!)

24. Entry Cache
It caches Objects
Hash map
Or
Ordered data structure

25. Cache, the bad
Locks...
Algorithms...
Memory...

26. Cache, the ugly
L Has to be 'warm'
L Immutable objects
=>
A kind of copy is needed
45% of the search processing time

27. DISK

28. Backend
Storage !

29. Backend
Remember :
memory vs disk latency...

30. Memory

31. Of Price and Men
Memory : 64 GB = 1000$
vs
1 day of consulting to 'tune'
your servers for little gain = ???

32. Machines

33. (Olivia) Newton (John) Theory
Let's get physical,
physical

34. VM vs Bare metal
http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

35. VM vs Bare metal
From 16h to 16 mins...
Most certainly IOs and/or disk access
(Spinning disks on a SAN)

36. Disk
Own your Disks !
Don't share them...
SSD is a winner !
SSD 1TB = 600$
HD 1TB = 100$

37. Network
Own your network !
Don't share it...

38. Network

39. Network
It's 4x to 40x times slower than memory :
Read 1 MB sequentially from memory ..... 250,000 ns
= 250 µs
Read 1 MB sequentially from SSD* ..... 1,000,000 ns
=
1 ms
Send 1 MB over 1 Gbps network ....... 10,000,000 ns
=
10 ms
But still : you can send up to 100 000 1kb entries per second
Through 1Gbps network...

40. Network
Get a fast network !

41. Misceallenous

42. Authorization
AUTHz
Is
Not
Free.

43. Thanks!