[Date Prev][Date Next]
Re: [ldap-nis] getgrent is slow
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
>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
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
openldap.org bug tracking system -- find ITS# 487 at
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().
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
May the Legos (TM) always be swept from your path in the night.