'[nssldap] groupOfNames performance'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nssldap
Subject:    [nssldap] groupOfNames performance
From:       Cove Schneider <cove_s () yahoo ! com>
Date:       2009-05-15 0:08:21
Message-ID: 87857.4287.qm () web110614 ! mail ! gq1 ! yahoo ! com
[Download RAW message or body]

Hi folks,

We are in the process of switching to using AD to store Unix directory information. \
Due to the size of some of our groups, we have to use the "member" attribute to store \
the DNs of the members vs. using memberUid. 

One issue however is that the enumeration of users' group memberships generates a lot \
of quires, and takes close to 1 second to complete. We're not entirely sure what the \
impact will be on our Linux desktop users, other systems that have performance \
requirements or the AD servers themselves just yet. (By comparison, our current \
lookups are < .1 seconds.) Nscd of course helps, but it does crash on occasion, and \
it does need to expire its cache eventually, at which point there could be a hang \
during the re-enumeration.

One of the things we were wondering about is since we are keeping all of our Unix \
groups under a single OU, nss_ldap doesn't really need to query each member of a \
group to determine if it itself is another group -- I'm assuming that's what's going \
on during the enumeration(?). It could short circuit this traversal if the base DN of \
the member is not under our group base DN. 

Does anyone have any thoughts here? 

Any info appreciated.

Thanks,

Cove



      


[Attachment #3 (text/html)]

<html><head><style type="text/css"><!-- DIV {margin:0px;} \
--></style></head><body><div style="font-family:times new roman,new \
york,times,serif;font-size:12pt"><div>Hi folks,<br><br>We are in the process of \
switching to using AD to store Unix directory information. Due to the size of some of \
our groups, we have to use the "member" attribute to store the DNs of the members vs. \
using memberUid. <br><br>One issue however is that the enumeration of users' group \
memberships generates a lot of quires, and takes close to 1 second to complete. We're \
not entirely sure what the impact will be on our Linux desktop users, other systems \
that have performance requirements or the AD servers themselves just yet. (By \
comparison, our current lookups are &lt; .1 seconds.) Nscd of course helps, but it \
does crash on occasion, and it does need to expire its cache eventually, at which \
point there could be a hang during the re-enumeration.<br><br>One of the things we \
were  wondering about is since we are keeping all of our Unix groups under a single \
OU, nss_ldap doesn't really need to query each member of a group to determine if it \
itself is another group -- I'm assuming that's what's going on during the \
enumeration(?). It could short circuit this traversal if the base DN of the member is \
not under our group base DN. <br><br>Does anyone have any thoughts here? <span \
class="yshortcuts" id="lw_1242344075_1"></span><br><br>Any info \
appreciated.<br><br>Thanks,<br><br>Cove<br></div></div><br>

      </body></html>



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic