FYI: unscd savings measurement

["Trent W. Buck" <twb-nss-pam-ldapd-users [at] cyber.com.au>]

Earlier this week I asked Arthur if nscd/unscd were worth the hassle,
since I've had a lot of grief from nscd-induced heisenbugs in the
past.

Arthur pointed out that reducing load on the ldap server was the main
reason to do it, but he didn't have any numbers on how much unscd
helped.

I just did a quick test on a PXE NFS/LDAP kiosk:

  1a. reboot it & install tcpdump
  2a. while "tcpdump tcp port ldap", log in & out three times.

  1b. reboot it & install tcpdump and unscd
  2b. while "tcpdump tcp port ldap", log in & out three times.

Stats are below.
Total Bytes appears to be down by an order of magnitude.
The NUMBER of ldap conversations is only reduced from eight to seven,
which I don't understand.

    $ tshark -qzconv,ip -zconv,tcp -rwithout-unscd.pcap | sed /=/d
    TCP Conversations
    Filter:<No Filter>
                                                   |       <-      | |       -> 
     | |     Total     |
                                                   | Frames  Bytes | | Frames  
Bytes | | Frames  Bytes |
    10.128.3.2:33277     <-> 10.128.0.1:ldap          109     17090      99     
14799     208     31889
    10.128.3.2:33278     <-> 10.128.0.1:ldap           62      9928      63     
 8763     125     18691
    10.128.3.2:33275     <-> 10.128.0.1:ldap           51      9116      60     
 7970     111     17086
    10.128.3.2:33276     <-> 10.128.0.1:ldap           54      9351      53     
 7594     107     16945
    10.128.3.2:33376     <-> 10.128.0.1:ldap           45      7862      45     
 6270      90     14132
    10.128.3.2:33379     <-> 10.128.0.1:ldap            5       438       9     
  758      14      1196
    10.128.3.2:33375     <-> 10.128.0.1:ldap            5       438       9     
  758      14      1196
    10.128.3.2:33370     <-> 10.128.0.1:ldap            5       438       9     
  758      14      1196
    IPv4 Conversations
    Filter:<No Filter>
                                                   |       <-      | |       -> 
     | |     Total     |
                                                   | Frames  Bytes | | Frames  
Bytes | | Frames  Bytes |
    10.128.3.2           <-> 10.128.0.1               336     54661     347     
47670     683    102331


    $ tshark -qzconv,ip -zconv,tcp -rwith-unscd.pcap | sed /=/d
    TCP Conversations
    Filter:<No Filter>
                                                   |       <-      | |       -> 
     | |     Total     |
                                                   | Frames  Bytes | | Frames  
Bytes | | Frames  Bytes |
    10.128.3.2:42967     <-> 10.128.0.1:ldap           20      2528      19     
 2510      39      5038
    10.128.3.2:42872     <-> 10.128.0.1:ldap           10      1044      11     
 1496      21      2540
    10.128.3.2:42969     <-> 10.128.0.1:ldap            8       676      12     
 1303      20      1979
    10.128.3.2:42971     <-> 10.128.0.1:ldap            5       438       9     
  758      14      1196
    10.128.3.2:42966     <-> 10.128.0.1:ldap            5       438       9     
  758      14      1196
    10.128.3.2:42873     <-> 10.128.0.1:ldap            4       479       5     
  580       9      1059
    10.128.3.2:42874     <-> 10.128.0.1:ldap            2       377       3     
  355       5       732
    IPv4 Conversations
    Filter:<No Filter>
                                                   |       <-      | |       -> 
     | |     Total     |
                                                   | Frames  Bytes | | Frames  
Bytes | | Frames  Bytes |
    10.128.3.2           <-> 10.128.0.1                54      5980      68     
 7760     122     13740


Just counting the requests & responses gives more believable numbers:

    $ tshark -r without-unscd.pcap ldap | wc -l
    504

    $ tshark -r with-unscd.pcap ldap | wc -l
    78

It looks to me like the savings are significant, proportionally.

Whether they're significant overall will of course depend on what
proportion of your network/cpu/ram/disk are spent servicing LDAP
requests.

For me, it's low, but I'll roll out unscd anyway and see how I go.

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/