Grouper Developers Forum

[Shilen Patel <>]

Shilen Patel wrote:
> > > > 5.  Listing group members also takes a long time.  If a group has X 
> > > > members and you want to see the first Y members, listing the group 
> > > > members causes at least X database queries and 2Y LDAP queries.
> > >
> > > Are you using the JNDISourceAdapter? Are those 2Y queries each in 
> > > their own ldap connection? Are the queried attributes suitably 
> > > indexed? Is the ldap server operated in a way that you expect should 
> > > produce quick response for the presented query load, ie, cache 
> > > tuning, ram, I/O for logging, etc?
> > >
> > > With grouper 1.2.0, the UI sorts membership and other types of lists 
> > > by default, which itself can increase display time. If X is 
> > > large-ish, enough to notice the time it takes to display, is it more 
> > > useful or less useful for the displayed list to be sorted?
> > >
> > > Do you have a sense for the threshold value of X at which this 
> > > becomes problematic, say, takes more than 1 sec to display?
> >
> > Yes, we're using the JNDISourceAdapter.  I'll get you some more 
> > information on where the time is spent later.  We're currently moving 
> > to a new test database sever.
>
> Each of the 2Y queries does its own LDAP connection and bind.  For 
> instance, I got the following from the ldap server log files when 
> viewing the members of a group that only has one member.
>
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=-1 msgId=-1 - fd=156 
> slot=156 LDAPS connection from ... to ...
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=0 msgId=1 - BIND 
> dn="..." method=128 version=3
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=0 msgId=1 - RESULT err=0 
> tag=97 nentries=0 etime=0 dn="..."
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=1 msgId=2 - SRCH 
> base="dc=duke,dc=edu" scope=2 
> filter="(&(duDukeID=0374183)(objectClass=duPerson))" 
> attrs="displayName displayName duDukeID"
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=1 msgId=2 - RESULT err=0 
> tag=101 nentries=1 etime=0
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=2 msgId=3 - UNBIND
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=2 msgId=-1 - closing - U1
> [09/Jul/2007:11:46:31 -0400] conn=24921832 op=-1 msgId=-1 - closed.
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=-1 msgId=-1 - fd=156 
> slot=156 LDAPS connection from ... to ...
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=0 msgId=1 - BIND 
> dn="..." method=12
> 8 version=3
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=0 msgId=1 - RESULT err=0 
> tag=97 nentries=0 etime=0 dn="..."
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=1 msgId=2 - SRCH 
> base="dc=duke,dc=edu" scope=2 
> filter="(&(duDukeID=0374183)(objectClass=duPerson))" attrs="uid 
> eduPersonPrimaryAffiliation displayName"
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=1 msgId=2 - RESULT err=0 
> tag=101 nentries=1 etime=0
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=2 msgId=3 - UNBIND
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=2 msgId=-1 - closing - U1
> [09/Jul/2007:11:46:31 -0400] conn=24921833 op=-1 msgId=-1 - closed.
>
> The ldap server is operating as expected and the queried attributes 
> are indexed.  I think there will always be a performance issue when 
> listing memberships if the number of ldap and database queries is 
> proportional to the number of members.
> As I was trying to answer the last two questions that you mentioned, I 
> noticed another problem.  For our smaller groups, the number of ldap 
> queries per person is significantly higher than 2Y.  I'm not noticing 
> a pattern without looking at the code.  But there were 13 queries for 
> a group with 3 members and 382 queries for a group with 37 members.  
> Though for a group with 400 members, while displaying the first 50, 
> there were 100 queries.  Any ideas?
>
> Thanks,
>
> -- Shilen

After taking a quick look at the UI code, I believe the multiple LDAP 
query problem (where the number of queries per subject is greater than 
2) is caused by the sorting in 
SubjectComparatorHelper.getComparisonString().  If comparator.sort.limit 
is larger than the size of the group, there will be more than 2 queries 
per subject.  Is this an expected behavior?

Thanks,

-- Shilen