Grouper Users - Open Discussion List

[Jorj Bauer <>]

Thanks Mark!

Sent from my iPhone

> On Jan 31, 2017, at 03:54, Mark Cairney 
> <>
>  wrote:
> 
> Hi,
> 
> I've found that using the sortVals setting on the member attribute
> significantly reduces the impact of this, as does using the mdb backend
> as opposed to bdb/hdb.
> 
> From the OpenLDAP docs:
> 
> olcSortVals: <attr> [...]
>    Specify a list of multi-valued attributes whose values will always
> be maintained in sorted order. Using this option will allow Modify,
> Compare, and filter evaluations on these attributes to be performed more
> efficiently. The resulting sort order depends on the attributes' syntax
> and matching rules and may not correspond to lexical order or any other
> recognizable order. This setting is only allowed in the frontend entry.
> 
> We're using this setting along with a couple of groups of >200K members
> and although CPU spikes for about 5-10 seconds when these groups are
> modified it hasn't as yet caused a service issue.
> 
> Kind regards,
> 
> Mark
> 
>> On 30/01/17 16:19, Michael R Gettes wrote:
>> None that I have from this quick interrogatory.
>> 
>> Sorry.
>> 
>> /mrg
>> 
>>> On Jan 30, 2017, at 11:00 AM, Jorj Bauer 
>>> <>
>>>  wrote:
>>> 
>>> Thanks.
>>> 
>>> Any data on whether or not specific OpenLDAP back-ends made significant 
>>> differences?
>>> 
>>> -- Jorj
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jan 30, 2017, at 10:50, Michael R Gettes 
>>>> <>
>>>>  wrote:
>>>> 
>>>> I received only a few replies.  Others have run into this limitation of 
>>>> openldap not being able to support large static group objects. The 
>>>> problem is really large numbers of multi-valued attributes (not just 
>>>> group objects).  My observation is 5 seconds to update when the group 
>>>> object becomes greater than 35K-40K members.  Apparently, openldap has 
>>>> to regenerate the member/uniquemember attributes for the entire object 
>>>> each time.  This appears to be a known issue with openldap since at 
>>>> least October of 2003.  People have switched to using 389/sun-oracle 
>>>> (the iPlanet derivatives) or Active Directory.  There are probably other 
>>>> directory servers able to support large group objects as well - but it 
>>>> would appear openldap and derivates have this problem.
>>>> 
>>>> i hope this helps.
>>>> 
>>>> /mrg
>>>> 
>>>>> On Jan 26, 2017, at 10:22 AM, Jorj Bauer 
>>>>> <>
>>>>>  wrote:
>>>>> 
>>>>> I'd love to hear an anonymized roll-up of what you find. We're in early 
>>>>> days of Grouper here and are picking a new LDAP back-end to replace our 
>>>>> Oracle DSEE - perfect timing for us to find out what our future 
>>>>> troubles are going to look like...
>>>>> 
>>>>> -- Jorj
>>>>> 
>>>>> 
>>>>>> On 01/26/2017 09:49 AM, Michael R Gettes wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> A few months ago there was discussion around large groups for grouper. 
>>>>>>  I believe someone from either UCLA or Oregon State (or maybe some 
>>>>>> place else) indicated they had groups of 400K.  Would those people 
>>>>>> kindly contact me off list?  I have a couple of questions for you - 
>>>>>> not about grouper perf concerns, but about non-grouper perf concerns.
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> /mrg
>>>>>> 
>>>> 
>> 
>> 
> 
> -- 
> /****************************
> 
> Mark Cairney
> ITI Enterprise Services
> Information Services
> University of Edinburgh
> 
> Tel: 0131 650 6565
> Email: 
> 
> PGP: 0x435A9621
> 
> *******************************/
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>