Experiences with large number of TS groups

Hi there,
this is with TS 6.7.2 on Solaris 10. We have been working with this setup for a while already, but as the number of branches increases there are some things we are getting concerned with (maybe unnecessarily so):

Does anyone have experiences with a TS system containing a large number of TS groups? We have set up thousands of groups so far, and there will be more to come, since for each branch we set up 7 groups in order to reflect our security architecture.
In addition to the large number of groups: does anyone know of limitations when it comes to nesting groups inside another? Is there a number of nesting levels that should not be exceeded?
Is there a difference between iwgroup's "add-member -group" and "add-included-groups" options (besides that one can be used to add more than one group at a time)?
Has anyone experienced a serious delay (I'm talking hours here) between making a user a member of a TS group and this change actually taking effect?
Is there a way to speed this up (emptying TS's "permissions cache" for instance)?

I appreciate any thoughts and input on these issues.
Thanks,
Tobias

Find more posts tagged with

Comments

Adam Stoller

Hi there,
this is with TS 6.7.2 on Solaris 10. We have been working with this setup for a while already, but as the number of branches increases there are some things we are getting concerned with (maybe unnecessarily so):
Does anyone have experiences with a TS system containing a large number of TS groups? We have set up thousands of groups so far, and there will be more to come, since for each branch we set up 7 groups in order to reflect our security architecture.
In addition to the large number of groups: does anyone know of limitations when it comes to nesting groups inside another? Is there a number of nesting levels that should not be exceeded?
Is there a difference between iwgroup's "add-member -group" and "add-included-groups" options (besides that one can be used to add more than one group at a time)?
Has anyone experienced a serious delay (I'm talking hours here) between making a user a member of a TS group and this change actually taking effect?
Is there a way to speed this up (emptying TS's "permissions cache" for instance)?
I appreciate any thoughts and input on these issues.
Thanks,
Tobias

Pawan

...
4. Has anyone experienced a serious delay (I'm talking hours here) between making a user a member of a TS group and this change actually taking effect? ...

We had this problem intermittently, even though we had few hundred groups only and few hundred users. The user gets access after few hours(4 or 5 hours) running iwreset brings no relief. Since, we couldn't reproduce this problem as and when required, support couldn't help us much. This is with TS671 SP1, Win 2003 Server.
Please post here what you hear from Support.

Sarang

Strangely, We have also been using similar set up with hundreds of groups and once we add any new user to a group, it takes about few minutes to get the access reflected. Would be interested to hear from Support too ( specifically on providing an option to add multiple TeamSite Groups at a time).

Sarang
TS 6.5 | Solaris 9

tobias

Hi everyone,
I've contacted Support in the meantime, and they pointed out a parameter in iw.cfg that seems to be undocumented (I couldn't find it in any official documentation):
[iwserver]
group_list_update_interval

According to support the default interval is 10 minutes, and since we don't have the parameter in the iw.cfg I guess the delay of several hour really is caused by the vast number of groups.
The support case is still open, but I doubt that they can present a way to significally speed things up.

The reason behind our large number of groups is that for access granularity we have one group per role per branch. Taking into account a number of 5+ roles (the basic TS roles plus some custom roles) and hundreds of branches this just amounts to thousands of groups.
We thought it might be easier and "cleaner" to not directly give a user access to a branch with a certain role, but to have a group instead, which a user simply can be added to.
Does anyone have a similar setup? Or what are your solutions for giving granular access permissions on an environment with hundreds of branches?

Modify IV.rptdesign

tobias

Hi everyone,
I thought I might share what became of this issue.

Apparently large numbers of non-OS TS groups (several thousand) lead to increasing user/group-cache recreating times (up to 6 hours in our case).

Apart from that we found that a setup that includes multiple nesting of groups, and users who each are members of large numbers of groups (in our case some users were members of several hundred groups each), which in turn are nested within other groups, causes TeamSite to perform excessive requests against its own permission cache, which has a negative impact on the overall performance.

As a result, each action of such a user produces such a heavy load that all other users are affected, partly giving the impression as if TeamSite is not reacting at all.

We changed our access and permissions model to get rid of these user-to-group and group-to-group nesting as far as possible. Now the users are directly attached to branches with their respective role(s).
This setup allowed us to reduce the number of groups substantially, which has a positive impact on the cache size and cache refresh times.
Also the setup completely eliminated the performance issues.

The only downside seems to be the lack of clarity and overview when it comes to checking the "Users and Roles" of a particular branch.

Cheers,
Tobias