CiviCRM scaling limits

[outinsun]

I'm wondering where CiviCRM 2.0's scaling limits are. Understand it depends somewhat on underlying hardware/database/etc. But I'm interested in where people have seen the software fall over in terms of:

1.Number of contacts
2.Number of groups
3.Size of a group
4.Size of a search result set
5.Number of mail recipients in a CiviMail mailing
6.Number of mailings
7.Number of tags
8.Number of custom fields
9.Number of search critieria
10.Number of relationships
11.Number of profiles
12.Number of ACL's/roles

[peterd]

Here's ours to start ball rolling
       

1	Number of contacts	50000
2	Number of groups	250 groups of which 144 Mailing Lists
3	Size of a group	30000
4	Size of a search result set	30000
5	Number of mail recipients in a CiviMail mailing	10000
6	Number of mailings	per day? total?
7	Number of tags	10
8	Number of custom fields	11 custom data groups, ranging from 5-20 custom fields, with some having 100 multi-select options
9	Number of search critieria	not clear what you mean but not hit any problems stacking four large smart groups
10	Number of relationships	10 types
11	Number of profiles	50 and rising
12	Number of ACL's/roles	used a different approach to get around difficulties of this

[geilhufe]

2.4M contacts back in 1.4
http://groups.drupal.org/node/811

[outinsun]

Number of mailings: per day? total?

Total, as it might effect the Browse Mailings page

Number of search critieria: not clear what you mean but not hit any problems stacking four large smart groups

I mean a complex search with lots of criteria AND'd and OR'd together

Number of ACL's/roles: used a different approach to get around difficulties of this

Can you say more about what the difficulties were and how you got around them? At what sizing point did you run into difficulties?

[peterd]

Number of mailings: per day? total?

Total, as it might effect the Browse Mailings page

250 so far (that haven't been deleted0. Don't think it would be an issue really as in there is a search function which quickly rattles through to help find earlier emails.

Number of search critieria: not clear what you mean but not hit any problems stacking four large smart groups

I mean a complex search with lots of criteria AND'd and OR'd together

Have to get back to you on that. But I have used the 'or SQL' on custom data that had 100 checkboxes - ie all 100 custom data options ticked and 'or SQL' selected - and didn't spot it running in to any problems on that.

Number of ACL's/roles: used a different approach to get around difficulties of this

Can you say more about what the difficulties were and how you got around them? At what sizing point did you run into difficulties?

Follow this thread. http://forum.civicrm.org/index.php/topic,3695.0.html Only downside that I can recall is that Users have access to the Tab that controls access. We haven't done any work to ensure this is not accessible. So as it stands it provides control ie people only see the subset of contacts that they should, but cannot yet lock them out of giving themselves access to more.

[outinsun]

Follow this thread. http://forum.civicrm.org/index.php/topic,3695.0.html Only downside that I can recall is that Users have access to the Tab that controls access. We haven't done any work to ensure this is not accessible. So as it stands it provides control ie people only see the subset of contacts that they should, but cannot yet lock them out of giving themselves access to more.

Apologies in advance if this is a naive n00b question, but would CiviCRM-OG integration solve the problem you were addressing in that thread? I also need to have groups of contacts where a contact can edit a subset of their own data and one or more "group admins" can edit a different subset of every contact's data within their group. I expect to have hundreds of such groups. This is the last piece of the puzzle to determine whether CiviCRM can work for me. Everything else (including the scalability responses in this thread) looks really good. Overall, based on initial evaluation, this is an extremely impressive piece of software.

[Donald Lobo]

the below can be done via profiles and using acls on profiles. i dont think it is related to OG at all

lobo

[outinsun]

the below can be done via profiles and using acls on profiles. i dont think it is related to OG at all

lobo

Can I do the following with profiles/acl's:

1. member of group A can edit fields 1-3 of their own contact data
2. member of group X can edit fields 2-4 of contact data for any member of group A
3. apply same logic to group B/Y pair
4. member of group A or B can't see any other contacts at all
5. member of group X can't see group B contacts
6. member of group Y can't see group A contacts

[Donald Lobo]

yes, you can do all the below with a combination of drupal my account (for group A/B editing own data), CiviCRM profiles with ACLs (for group X editing data for A and Y for B)

I'm assuming u r using 2.1 (if not i'd recommend using it . For large number of groups, u can implement your own specialized ACL hook (which is what the NZ green party did). This will be way more efficient and scalable that the civicrm acl structure (which in more generalized etc)

lobo

[outinsun]

yes, you can do all the below with a combination of drupal my account (for group A/B editing own data), CiviCRM profiles with ACLs (for group X editing data for A and Y for B)

Fabulous.

I'm assuming u r using 2.1 (if not i'd recommend using it . For large number of groups, u can implement your own specialized ACL hook (which is what the NZ green party did). This will be way more efficient and scalable that the civicrm acl structure (which in more generalized etc

I am not using 2.1. I'm still on Drupal 5. Not all the modules I need have been ported to 6. Most notably LDAP Integration. I am expecting that integrating LDAP, Drupal, OG, and CiviCRM will be most entertaining. At the moment, however, knowing that by hook or by crook I can accomplish the things I need in CiviCRM at the scaling level I need is good news.

[geilhufe]

check this for LDAP:
http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+LDAP+Integration

[outinsun]

check this for LDAP:
http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+LDAP+Integration

"No support for CiviCRM groups exists." Hmm..I'm hoping to use LDAP as a canonical repository for user AND group information that needs to be used by multiple systems, including but not limited to Drupal/OG and CiviCRM. Sounds like I may be pointing myself in the code contribution direction again. 

[outinsun]

I'm wondering where CiviCRM 2.0's scaling limits are.

I forgot to ask about:

1. number of simultaneous events
2. number of events that can be mapped at once (I'm assuming you can map a group of events and not just one)
3. number of contacts that can be mapped at once

Thx.

[peterd]

From memory I have selected hundreds and mapped them no problem.