Speeding up nscd

[Andreas Jaeger]

On 12/27/2012 01:07 AM, Petr Baudis wrote:
>    Hi!
>
> On Wed, Dec 26, 2012 at 09:10:49PM +0200, Dimitrios Apostolou wrote:
>> Hi Petr, interesting insight I didn't know of, so I went ahead and
>> found "unscd" at [1]. Here is a part of the initial comment:
>
>    Right. To balance that, there are at least two downsides to unscd:

One more: Sometimes the interface between nscd and glibc changes - and 
then unscd has to catch up. For example unscd 0.48 was released to fix 
such a change introduced in glibc 2.15.

>    * It is/used to be not as tested as nscd and there are some bugs
> in it too.  A different set, and *maybe* smaller.
>
>    * 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). This is not the case with unscd where queries
> will start new connections. It may be similar with regards to other
> NSS modules as well.
>
>    It's no panacea, and in a hindsight it's not as simple as replacing
> nscd with unscd and being happy to the end of our days. But it is an
> alternative to seriously consider.

Also, AFAIK unscd does not support all databases that nscd supports,

Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126