Download as PDF, PPTX
![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](https://image.slidesharecdn.com/ldap-fast-131120044125-phpapp02/85/What-makes-a-LDAP-server-running-fast-An-bit-of-insight-about-the-various-bottlenecks-and-solutions-to-avoid-them-7-320.jpg)
Uploaded byLDAPCon
What makes a LDAP server running fast ? An bit of insight about the various bottlenecks and solutions to avoid them
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.
More Related Content
Similar to What makes a LDAP server running fast ? An bit of insight about the various bottlenecks and solutions to avoid them
What makes a LDAP server running fast ? An bit of insight about the various bottlenecks and solutions to avoid them
- 1. What makes aLDAP server running fast ?
- 2. Emmanuel Lécharny Apache SoftwareFoundation 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 programmershould 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.
- 5. Search : Fromclient to client
- 6.
- 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.
- 9. Search, search, search It'sall about Search performance !
- 10.
- 11. Search Request Checks Checksdone 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.
- 13. Selecting candidates Candidates arereferences 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 & ANDfilter Maximum = min(filters candidates) Minimum = min(filters candidates) Here, max = 72 and min = 72
- 16. Candidates & ORfilter Maximum = sum(filters candidates) Minimum = sum(filters candidates) Here, max = 8098 and min = 8098
- 17. Cost of creatingcandidates Looking for the best index + Creating the set of references = 20% of the search processing
- 18.
- 19.
- 20.
- 21.
- 22. Reminder Disk is from4x 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 NoDisk access => Fast (very!)
- 24. Entry Cache It cachesObjects Hash map Or Ordered data structure
- 25.
- 26. Cache, the ugly LHas to be 'warm' L Immutable objects => A kind of copy is needed 45% of the search processing time
- 27.
- 28.
- 29. Backend Remember : memory vsdisk latency...
- 30.
- 31. Of Price andMen Memory : 64 GB = 1000$ vs 1 day of consulting to 'tune' your servers for little gain = ???
- 32.
- 33. (Olivia) Newton (John)Theory Let's get physical, physical
- 34. VM vs Baremetal http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/
- 35. VM vs Baremetal 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.
- 39. Network It's 4x to40x 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 fastnetwork !
- 41.
- 42.
- 43.