Grouper Users - Open Discussion List

[Rahul Doshi <>]

Hi Shilen,

I followed your steps and I am no longer seeing performance problems even without adding indexes.  Thanks for the suggestions.

Rahul

From: Shilen Patel <>
Date: Tuesday, August 28, 2012 8:54 AM
To: Rahul Doshi <>, "" <>
Subject: Re: [grouper-users] grouper ldap loader and performance

Hi,

If you're willing to debug this a bit more, I wanted to see if you could do the following:

1.  You may have already tried this, but drop those 4 indexes that you added and analyze your tables.  If you're running mysql (I thought I saw a previous email from you indicating that you were), you can analyze by running:

ANALYZE TABLE grouper_groups;

ANALYZE TABLE grouper_memberships;

ANALYZE TABLE grouper_group_set;

Does that improve performance?

2.  If it's still slow, if you just add the following 2 of the 4 indexes, is it still slow?

CREATE INDEX my_index2 ON grouper_memberships(field_id);

CREATE INDEX my_index ON  grouper_group_set (member_field_id);

Thanks!

-- Shilen

From: Rahul Doshi <>
Date: Fri, 24 Aug 2012 20:18:07 +0000
To: "" <>
Subject: Re: [grouper-users] grouper ldap loader and performance

Just to followup on my earlier question I was able to find the query that was taking too long by enabling p6spy.  I am copying the query .  Also I was able to improve the performance by adding below indexes.

CREATE INDEX my_index ON grouper_memberships(owner_id);

CREATE INDEX my_index2 ON grouper_memberships(field_id);

CREATE INDEX my_index ON  grouper_group_set (member_field_id);

CREATE INDEX my_index ON  grouper_group_set (member_id);

  select distinct group0_.id as id21_,

     group0_.hibernate_version_number as hibernate2_21_,

     group0_.last_membership_change as last3_21_,

     group0_.last_imm_membership_change as last4_21_,

     group0_.parent_stem as parent5_21_,

     group0_.creator_id as creator6_21_,

     group0_.create_time as create7_21_,

     group0_.modifier_id as modifier8_21_,

     group0_.modify_time as modify9_21_,

     group0_.name as name21_,

     group0_.display_name as display11_21_,

     group0_.extension as extension21_,

     group0_.display_extension as display13_21_,

     group0_.description as descrip14_21_,

     group0_.context_id as context15_21_,

     group0_.alternate_name as alternate16_21_,

     group0_.type_of_group as type17_21_

from

     grouper_groups group0_  cross join grouper_memberships_all_v

membership1_

where

     membership1_.owner_group_id=group0_.id and (

         membership1_.field_id in (

             '294fc6a4c8c64ae29927f224e855b26f' ,

             'b4ea987c08dd4857b860331207ec6e7c' ,

             '7182ccd82892472e980e0bf62eba2984' ,

             'a649527c7dcb40ceaa5d6f9d2dbbc8f2' ,

             'da287d5273a34566bebac16cb20e5064' ,

             '12b77693512f4d07945436b28bccc0e6')) and

(membership1_.member_id

in (

                 '6910d4aa11754890a183a0b65abd7bd6' ,

                 '417bbc85ba91452a95815b7196e17868')) and

     membership1_.immediate_mship_enabled='T' and

     group0_.parent_stem='f7470369f3174db6b6b283c09370c019'

Thanks,

Rahul

From: Rahul Doshi <>
Date: Friday, August 24, 2012 10:33 AM
To: "" <>
Subject: [grouper-users] grouper ldap loader and performance

We have a use case where we need to load about 3000 ldap groups with roughly 125k membership into grouper.  Members of the group by default should have read privilege to the group and non-members just view.  To achieve this  first I tried to implement a custom EL class that would assign a read privilege to the group itself.  For example somestem:somegroup has read privilege to somestem:somegroup.  This worked but links like My memberships and Manage Groups took really long time in grouper UI.  So next I tried to implement membershipPostCommitAddMember method of the MembershipHooks which would just grant read privilege directly to the subject that is added.  This improved performance considerably but still it takes about 25 seconds for My membership link to return.  I believe I am seeing improved but still bad performance because I didn't completely  eliminate nested membership as we have lot of nested groups so my custom membership hook will still assign read privilege at the group level.

Am I taking the right approach to achieve what I want?  Is there something simpler that can be done and not have performance problems?

Thanks,

Rahul