15

CiviCRM is distributed under a GNU AGPL 3 license; there are no legal limits as to the number of contacts or number of users you can have. On the question of storage, it isn't easy to say definitively what a maximum number of contacts would be, or even how much disk space a certain number of contacts would require. Contacts are only a small part of a CRM ...


11

If logging is on then results will be retrieved from the log_xxx tables not civicm_log. Normally these tables use the archive engine - which is not indexable. We have in some cases selectively converted these to INNODB & added indexes Archive tables are supposed to be quick to write to and slow to read from. They are also non-transactional - which ...


10

To speak to your question about whether 10k or 25k might be too big for CiviCRM, I think everyone has a different personal take on what constitutes a "big" database, and use-cases do vary a lot, but from talking to different Civi users I get the general sense that (very roughly): A "small" database is < 100k contacts A "medium" database is 100k - 1M A "...


6

The slowest part of upgrading on a large installation is usually the civicrm_mailing_event_* tables. That data is also often stale, so consider deleting it if you don't need to keep historical information about past civimailouts.


6

Best to review the tables which are largest in your DB, and also identify which queries during the upgrade take the longest. This is a chicken-and-egg problem, which means you might review the tables you "lighten" as you work through the upgrade process. Here's something I was using a few years ago on fairly heavy DB. This would exclude data in those tables ...


6

Most recent installs I have done of CiviCRM seem to behave best with 2gig minimum of memory. 1.5gig should work as a minimum, but memory is cheap so go with 2gig. We typically use eApps for most of our clients. They have a nice interface to easily adjust your resources up and down as you need: memory, cpu, disk space. Being able to easily raise and lower ...


6

1) There is no imposed restriction on the number of contacts. MySQL has some theoretical limit that your would reach if you entered every person on the planet multiple times. 2) As @choster spells out so thoroughly, every implementation is different so we can't say for sure what it will take. Unless you have a tremendously rich and complex contact record, ...


6

It's tempting to discard this question as being too vague to give an accurate answer to, but capacity planning is a real and difficult challenge. Is CiviCRM resource intensive? That depends what you compare it with - compared to a static site, yes. A CiviCRM site with a few users occasionally looking up a contact needs far fewer resources than one with ...


4

This problem is not to do with CiviCRM. My server defaults to using ipv6 but this is not configured. Therefore when CiviCRM tries a file_get_contents('http...') it is timing out. This vexed me for a while because on the command line wget works fine; I thought I had disabled ipv6 on the server, but turns out file_get_contents doesn't know about that. Sorry ...


4

A great resource as you sort out hosting is a talk by Peter Petrik from Skvare at CiviCon Denver: CiviCRM Hosting & Performance Optimizations For other Civi provider options, see CiviCRM Hosting Providers. For what it's worth, I would recommend at least 2GB of Ram for a Civi install. We use Media Temple VPS hosting. We started with their 4GB Ram ...


4

They are several distinct issues: Calling civicrm_api3, this isn't REST, and (unless requested) the code runs as admin, so probably not linked with authentication Here, a common issue is the database access, the first time you access the underlying tables (civicrm_contact and co), mysql might not have kept them in the cache, but the second time they are ...


4

For the specific case of upgrading to 4.7, here's a useful tip from Dave Jenkins : https://issues.civicrm.org/jira/browse/CRM-18526#comment-106825 In short: upgrading to 4.7 involves multiple changes (4 or 5?) to foreign keys on two tables that are often very large. In order to do this, mysql makes copies of those tables for each change, which can take a ...


3

Consider moving your MySQL folder to a RAM disk. This is NOT recommended for a production upgrade, but could speed a dev/test site upgrade! See here for a script. Folks often report a 50x speedup - but I suspect that's vs. a spinning disk. I get roughly 2.5x speedup compared to SSD.


3

If you're lucky, you just need to turn on the php op-code cache. My experience using on Centos6 was that it wasn't on by default. But I'm intrigued if your slow execution time is specific to CiviCRM. If it isn't, your server specs sound reasonable, but there are many devils in the details, and I'd tend to agree with Hershel that you should go back and make ...


3

This would appear to be a fairly general question of Linux server optimization, which is a complicated subject. The details of such optimization depend on a myriad of factors and settings and is, generally speaking, not the kind of thing that can be answered on a site like this--it depends as much upon the hardware as it does on the software and settings. ...


3

I think this would be a relatively simple fix. I'd suggest you file an issue for this and, ideally, provide a patch... ...actually in fiddling around with this I just wrote a patch that fixes it. Try this: #6283 Don't force-refresh the changelog tab to avoid performance overhead


3

For people googling, I significantly increased the speed of the Change Log by following Eileen's advice in her answer: convert some tables (activity, activity_contact, contact, group, group_contact) from ARCHIVE to INNODB, and adding indexes. The Change Log still takes ~20 seconds to load, but that's much better than the minutes it used to. We've taken a ...


3

There are certainly instances with much larger numbers of contacts than you are describing. We have several in the range of .5-1 million contacts and of course the associated activities etc. And there are others out there much larger than those. If it performance you are concerned about, rather than the number of rows in tables like _contact and _activities,...


3

Do you have a few smart groups on which many others depend? If so it's worth making sure they're as quick as possible. We have a script that generates the important ones once per hour - but by putting the contacts into regular groups, rather than smart groups. Regular groups are much faster, and that speeds things up a bit. We've also turned off smart group ...


2

You may be running into performance issues if you have groups in your Search Builder queries. See CRM-16483.


2

Take a look at the INNODB logging extension. It converts the log table format from ARCHIVE to INNODB, adding indexes and speeding up as a result.


2

The log tables as originally implemented (I have checked for a few years if this is the case) also contain a large number of superfluous records due to writes that don't actually change the data. Improving the triggers to check for a difference between old and new values before the write to log would improve things for everyone.


2

Skvare has worked with a number of CiviCRM implementations with data sets of significant size. As has been mentioned, do expect to have a bit of a "learning" curve - especially with the LAMP stack setup. It will require a well-tuned VPS. Data handling will be another major challenge. First, small variations in addresses, prefix or suffix fields, etc. ...


2

CiviCRM handles large datasets fine. There are 100+ sites with more than 250k contacts (https://stats.civicrm.org/?tab=sites). You will need to ensure that the server used is powerful enough. To save some money, you can improve performance on a smaller server by turning off some things, in particular Administer > Customize Data and Screens > Search ...


2

I've never used Civi with a dataset that large, but there are some general scaling principles that apply to Civi as with any other system. The most important one I learned is that work = size * complexity. Okay, that might be a bit of an exaggeration, and in some ways, size doesn't matter very much at all (e.g. you can simply scale your servers to some ...


2

First you should fix "Total fragmented tables: 868". And it does seem your amount of RAM is too small. But you could first increase innodb_buffer_pool_size to 2.5GB and join_buffer_size to 16M Maybe then MySQL can run a bit longer, so you get a better quality output of mysqltuner. Personally I would say all of the following are on the low side: ...


2

@Aidan is right - there is no one number for how many sites - not even a 'more or less' number :-) Some of our projects are on one dedicated server that hosts a couple dozen of them; they are all Drupal (and most with CiviCRM). Another project though -> it has its own two dedicated servers: one for web and one for the database/mysql!


2

Several organizations use CiviCRM with similar needs. Wikimedia Foundation and Australian Green Party have very similar requirements, for example.


2

I suggest you delete the UI_case_contact_id index as suggested by CiviCRM, and then refresh the system status page. It should then present a button which will automatically add missing indexes.


2

I had a lot of trouble tracking down a problem that sounds the same. We ARE behind a firewall so pingbacks to CiviCRM etc WILL timeout. The last piece of the puzzle (once normal version checks were disabled) was adding this to civicrm.settings.php global $civicrm_setting; $civicrm_setting['CiviCRM Preferences']['communityMessagesUrl'] = FALSE;


Only top voted, non community-wiki answers of a minimum length are eligible