How many groups and applications can we manage in 1 Crowd instance?
Asked by Archanaa Panda:

Hi,

1. I believe there is a maximum limit of 10000 users beyond which crowd's performance degrades and caching is not suggested.

Is there a limit for groups as well?

Currently, we are creating 2 groups per project because we are also managing subversion repository permissions with Crowd. We would have around 5000 projects which would mean 10000 groups, though users may be within the 10000 limit. Are there any limitations in crowd to handle this number of groups?

2. Also, is there a limit to the number of application instances of JIRA, Confluence and fisheye that 1 crowd instance can support to provide Single Sign On (SSO)?

3. When we connect a JIRA/Confluence/Fisheye application to 1/more crowd directories, does the application synchronize \*all\* the users and group memberships and groups of those directories and store it in its embedded crowd tables? Or is it only the users and the users' group memberships that are currently accessing the application?

Does this pose a limit to how many users and groups we can have in crowd per directory or per application that we are mapping?

4. If there any limitations for above questions, please specify what limitations are only related to slight loss of performance and which ones are completely unsupported by Atlassian support.

Understanding of these limitations up front is very important as we are planning out our enterprise roll-out and are taking major architectural decisions.

We are currently using Crowd 2.4.2 but we can upgrade if there are any enhancements related to this in the latest version of crowd, so please advise accordingly.

Thanks and Regards,

Archanaa


Answers:
author: fsim
body: Answered this is SAC, but I figured this will help other customers as well:
> Is there a limit for groups as well?  
>
> Currently, we are creating 2 groups per project because we are also managing subversion repository permissions with Crowd. We would have around 5000 projects which would mean 10000 groups, though users may be within the 10000 limit. Are there any limitations in crowd to handle this number of groups?

Actually, not really. Even the 10000 user limit is just a best-practice, to be honest, and we even have customers running Crowd with more than 60K users without any problems at all. Of course, we don't recommend it, but it won't break Crowd, nor will it cause a significant performance degredation (unless you are trying to sync 1 directory with 60000 users in 1 go, or sync all directories at the same time).
> 2. Also, is there a limit to the number of application instances of JIRA, Confluence and fisheye that 1 crowd instance can support to provide Single Sign On (SSO)?

No limit at all, to my best knowledge, as long as each of these apps sit in their own context paths. For example:  
http://localhost/crowd for Crowd  
http://localhost/jira for JIRA  
http://localhost/jira2 for the 2nd instance of JIRA  
http://localhost/conf for Confluence  
http://localhost/confluence for 2nd instance of Confluence  

etc. This is just an example  

> 3. When we connect a JIRA/Confluence/Fisheye application to 1/more crowd directories, does the application synchronize all the users and group memberships and groups of those directories and store it in its embedded crowd tables? Or is it only the users and the users' group memberships that are currently accessing the application?  
> Does this pose a limit to how many users and groups we can have in crowd per directory or per application that we are mapping?

It will synchronize all the users and groups from all the directories that are mapped to the application in {{Crowd \>\> Applications}}. The limit will depend on your application. For example, Confluence has a limit of 10,000 users as well (the best-practice limit, but if you have Confluence unlimited user license, this shouldn't be a concern).   

We will still support you in case you run into any issues. Of course, our advice will be for you to integrate Crowd to LDAP via Delegated directory (if you are using LDAP), instead of the conventional Connector directory, if your LDAP users are indeed, more than 10000 users. The performance degredation with Delegated directories and a large user base is very minimal, so that is normally what we advice our customers to use.   

Crowd 2.5.2 introduces quite a few features that makes setting up SSO significantly more painless, but there are not too many performance advantage, so you can still live with 2.4.2.   

Hope this answers your questions. Do let me know if you have any doubts.  

Thanks and Regards,  
Foogie


Tags: crowd

group

limit

performance

sso

user