Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

> > 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?

The following key in media.properties controls the sort limit
comparator.sort.limit=200

The bigger issue is likely to be the fact I process all the memberships in 
order to `de-duplicate` and indicate in the UI where a membership is in 
fact present for > 1 reason.


> > 7.  The xml-import takes about 3-4 days for us and requires 4 GB of
> > memory allocated to the Java process.
>
> It appears that the current DOM-based xml import/export approach does not
> scale. We (ie, the grouper-dev community) should settle on an
> alternative. Other JAXB-supported xml processing modes? A gsh-based
> approach?
I think we need to understand better where the problem lies.  i.e. how much 
time is spent parsing the XML and figuring out which API calls to make vs 
making the API calls. I`m sure another approach will be called for but we 
should understand what we will gain by changing the current one.




----------------------
GW Brown, Information Systems and Computing