Re: nss-pam-ldapd slower than nss_ldap
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: nss-pam-ldapd slower than nss_ldap
- From: Arthur de Jong <arthur [at] arthurdejong.org>
- To: 飞侠 <24537248 [at] qq.com>, nss-pam-ldapd-users <nss-pam-ldapd-users [at] lists.arthurdejong.org>
- Subject: Re: nss-pam-ldapd slower than nss_ldap
- Date: Thu, 09 May 2013 14:01:55 +0200
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/