Grouper Users - Open Discussion List

[Shilen Patel <>]

We discussed this on the call yesterday and decided to add a new column 
to the grouper_groups table.  The new column would be similar to 
last_membership_change except it would only take into account immediate 
memberships.

https://bugs.internet2.edu/jira/browse/GRP-571

If anybody else is using last_membership_change, please let me know how 
you're using it so we can be sure to take your use case into account.

Thanks!

-- Shilen


On 3/1/11 4:48 PM, Shilen Patel wrote:
> Right.  The last_membership_change of a group is updated when that
> group's immediate, effective, or composite memberships change.
>
> Thanks!
>
> -- Shilen
>
> On 3/1/11 3:46 PM, Jim Fox wrote:
>    
> > I think I misunderstood something.  Does last_membership_change mean
> > last effective membership change?  That would indeed explain the many updates,
> > probably with some locking as well.  I can see why it is optional.
> > Possibly in the future the sense of direct or effective of that timestamp
> > could be switchable.
> >
> > It's a lot of work keeping 'effectiveness' up to date, especially
> > when nested groups are common.  That's why we tend to compute
> > effective things on the queries.
> >
> > Jim
> >
> >
> >
> >
> >      
> > > Do your membership changes often cause a lot of effective membership changes?
> > > If so, that update statement would be updating a lot of groups.  Otherwise,
> > > have you tried to see if analyzing your tables (grouper_groups and
> > > grouper_group_set) helps?
> > >
> > > Thanks!
> > >
> > > -- Shilen
> > >
> > > On 3/1/11 1:54 PM, Jim Fox wrote:
> > >
> > >        
> > > > A couple of weeks ago I activated the update of membership changes:
> > > >
> > > >       groups.updateLastMembershipTime = true
> > > >
> > > >
> > > > This did update membership change times, but also caused a major
> > > > hit on our postgres DBMS.  Response times on our web service
> > > > went from 1-2 sec to 5-10 sec.  Looking at the database we saw
> > > > continually running update statements like:
> > > >
> > > >       update grouper_groups set last_membership_change = $1 where id  in ($2,
> > > > $3...)
> > > >
> > > > As soon as one completed another started - or so it seemed.
> > > > The load average on our DB server went from below 1 to above 7.
> > > > Setting the updateLastMembershipTime back to false removed the
> > > > update commands and immediately improved response times.
> > > >
> > > > This is standard grouper 1.6.0.  During normal daytime operations
> > > > we see membership changes every five to ten seconds.
> > > >
> > > > Jim
> > > >
> > > >
> > > >
> > > >          
> > >
> > >        
>