?????? nss-pam-ldapd slower than nss_ldap

["????" <24537248 [at] qq.com>]

thanks very much!

I have resolved this problem.

 

[root@ldap1 ~]# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search localdomain
#nameserver 192.168.231.2
[root@ldap1 ~]#

When i noted the line nameserver, and excuted the ldapsearch command , there was ouput normally.

regards!

------------------ ???????? ------------------

??????: "Arthur de Jong"<arthur@arthurdejong.org>;

????????: 2013??5??9??(??????) ????8:01

??????: "????"<24537248@qq.com>; "nss-pam-ldapd-users"<nss-pam-ldapd-users@lists.arthurdejong.org>;

????: Re: nss-pam-ldapd slower than nss_ldap

On Wed, 2013-05-08 at 09:37 +0800, ???? wrote:
> according your reply,  i excuted the command "ldapsearch -x ", and
> "lsof | grep ldapsearc" at the same time, i found that  waiting at UDP
> connected  status, the reason could be  authentication mode. how i
> configure the  nss-pam-ldapd policy.

As the output from lsof indicates, the NSS module is not loaded (no
libnss_ldap.so file in the list) so this is not related to
nss-pam-ldapd.

The open UDP connection is for DNS lookups. It could be that your DNS
server is slow or resolv.conf is incorrectly configured. Pretty hard to
tell from the output you provided and also off-topic for this list.


Your post did prompt me to re-run some performance comparisons between
nss_ldap and nss-pam-ldapd. It turns out that nss_ldap is roughly 15%
faster with big results but nss-pam-ldapd is 20-70% faster in other
cases.

It also seems that the default number of threads (5) that nscd starts is
still a reasonable choice since it delivers good performance, even under
very heavy load.

A quick test with 0.9.0 also indicates that it is 1-3% faster than the
0.8 series.

The results of the four tests (number are requests handled per second):

                            T1   T2    T3    T4
nss_ldap 264-2.5           9.3  9.5  36.5   ---
n-p-l 0.8.10 1 thread     16.1  9.8  30.1  30.1
n-p-l 0.8.10 3 threads    16.3  9.7  30.3  30.0
n-p-l 0.8.10 5 threads    16.1  8.4  44.3  43.3
n-p-l 0.8.10 10 threads   16.2  8.4  45.6  44.1
n-p-l 0.8.10 50 threads   16.2  8.3  44.2  42.8
n-p-l 0.9.0  5 threads    16.3  8.6  45.4  44.7

The tests were:
  T1: request one passwd entry (100 sequential requests)
  T2: request all passwd entries (100 sequential requests)
  T3: various requests (10 times 100 parallel requests)
  T4: various requests (1000 parallel requests)

The conditions of all tests were similar (Debian chroot environment,
mostly idle system otherwise, 5 runs of each test eliminating outliers,
LDAP database accessed through ldapi:/// with 2000 users, nscd not
running).

There are no figures for T4 for nss_ldap because it was failing under
such heavy load. It started to return lookup errors for a significant
portion of the request, probably because of hitting the LDAP server
limits.

Kind regards,

--
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

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