Full_Name: Karl O. Pinc Version: 1.2.9-5 OS: Linux, RedHat 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.40.24.216) It appears that even when ldap_result is called with the "all" argument set to 0, the entire query result is tranfered over the network for each ldap_result call. When the result set is large, performance is terrible. I'm running nss_ldap version 105, and trying to use ldap to store unix groups. Programs that getgrent (which returns "the next" group entry) through the group database takes 7 seconds/getgrent call. We've about 6000 entries in the group table. This is clearly unusable. Let me know if you need more info. Thanks for the work.
At 07:09 PM 3/21/00 GMT, kpinc@artic.edu wrote: >It appears that even when ldap_result is called with the "all" argument set to >0, >the entire query result is tranfered over the network for each ldap_result >call. The parameters of ldap_result to not affect how the server responds to requests, they affect how ldap_result behaves while parsing the server provided results. See ldap_result(3) for details. >When the result set is large, performance is terrible. Issue requests that result in smaller results, but... >I'm running nss_ldap version 105, and trying to use ldap to store unix groups. >Programs that getgrent (which returns "the next" group entry) through the group 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 setgroupent()/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().
changed notes changed state Open to Closed
close per submitter request