Re: [ldap-nis] getgrent is slow

["Karl O. Pinc" <kpinc@artic.edu>]

Ok, I was wrong about this.  I think I see a problem in the ldap-nis code.
Those who care can read on.

>The problem is in openldap.   Calls to ldap_result() with "all" = 0 (return
>1 result) have the server transfer the entire query result to the client
>for each call.
>
>Although caching in nss_ldap might help, that kind of overhead is clearly a
>no-no.
>
>Anybody know if there's any chance of this being fixed in openldap?  (I'm
>using 1.2.9 now.)
>>>>On 15 Mar, Karl O. Pinc wrote:
>>>>> Very slow.  To the point that looping through the group file is unusable.
>>>>> Does anybody have any solutions?
>>>>>
>>>>> I'm using openldap, and I think it's compiled to be ldap version 2
>>>>> compliant.  Does ldap 3 solve this?

To recap: each getgrent takes a long time and transfers _all_ the groups
from server to client.


Here's my take on what's going on in ldap-nis (version 106):
(Linux 2.2.12, RedHat 6.1, openldap 1.2.9-5, obviously this is a GNU_NSS
system)

in ldap-nss.c

Each getgrent call winds up being a call to nss_ldap_getent.

_nss_ldap_getent calls do_parse, which calls do_result, which sets the
ec_msgid ent_context_t structure element to -1 whenever async calls are
being made (all=0).  -1 is the result returned by ldap_search on error and
is the flag to _nss_ldap_getent that there is no search in progress.  So,
_nss_ldap_getent _always_ calls _nss_ldap_search, which calls ldap_search.
So each getgrent call results in a new ldap_search call.

Kurt D. Zeilenga (openldap maintainer) writes in
http://www.openldap.org/its/index.cgi/Incoming?id=487;user=guest (the
openldap.org bug tracking system -- find ITS# 487 at
http://www.openldap.org/its/index.cgi): <quote>

As entries in containers are not orderred, I would suggest that one ldap search
be issued for each sequence of getgrent() calls made by application (sets
delimited by getgroupent()/setgrent()/endgrent() calls).  One could use
ldap_result(all=0) to set through the results as needed for getgrent() or
use ldap_result(all=1) and ldap_first/next_entry().

</quote>

So, what's happening in ldap_nss.c is contrary to Kurt's recommendation.

I don't know why do_result is setting ec_msgid to -1.  I sort of get the
vibe that ent_context_t needs another element to keep track of some other
state.  I don't have time to do more with this so yall are on your own from
here.

Karl

May the Legos (TM) always be swept from your path in the night.