This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Speeding up nscd

From: Florian Weimer <fweimer at redhat dot com>
To: libc-alpha at sourceware dot org
Date: Tue, 08 Jan 2013 09:53:52 +0100
Subject: Re: Speeding up nscd
References: <alpine.LFD.2.02.1212260413530.1646@soupermouf> <CAE2sS1gCrUtd1mEXA6h2iQAo=MFmXNxxRoueSbtwZGZ4-GkK-g@mail.gmail.com> <20121226050907.GA10003@spoyarek.pnq.redhat.com> <alpine.LFD.2.02.1212261049250.1646@soupermouf> <20121226103154.GA7184@domone> <20121226184740.GA18195@machine.or.cz> <alpine.LFD.2.02.1212262106370.1646@soupermouf> <20121227000702.GB18195@machine.or.cz>

On 12/27/2012 01:07 AM, Petr Baudis wrote:

   * Since all resolving is done in separate children, NSS cannot
reuse resources between the children. For example, IIRC nss_ldap
likes to reuse a single connection to the LDAP server for all the
queries; one of the big reasons to use nscd (at least for some) is to
keep LDAP connection count low for servers handling huge deployments
(thousands+ of clients).

In general, it is not safe to perform complex operations in NSS (or PAM) modules because there's so little known about the surrounding process. That's why nss_ldap was with nss_ldapd, which does the heavy lifting in a separate daemon. Over time, all complex NSS/PAM modules will move to this model.

--
Florian Weimer / Red Hat Product Security Team

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]