What makes a LDAP server running fast ? An bit of insight about the various bottlenecks and solutions to avoid them
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

What makes a LDAP server running fast ? An bit of insight about the various bottlenecks and solutions to avoid them

  • 1,148 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,148
On Slideshare
1,061
From Embeds
87
Number of Embeds
1

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 87

http://lanyrd.com 87

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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!