The quest for performance improvements
After the socialist party upgraded civicrm to version 4.6 a month ago they are experiencing performance issues. In this blog I will round up our quest for performance improvements. But before that some facts about their installation.
- +/- 350.000 contacts
- +/- 300 users who can access civicrm and see members in their local chapter
- +/- 2700 groups
- There are several campaign websites linked to CiviCRM and one of their successfully campaigns leads to 7500 new contacts per week in the system
- Running on a VPS with 4 CPU cores and 8GB of RAM
- around 40 active extensions
Since yesterday we have added New Relic as a monitoring tool. With New Relic we can monitor and look back in the history. We can also see all the details in each request. So we can analyze the performance.
Above is the screenshot of the monitoring of the last 24 hours. The red/rose squares indicates when the overall performance is poor (more than 2 seconds per request). We also see that MySQL has a big part in the largest peaks.
The screenshots above shows the slowest queries and the slowest mysql operations. One observation is that it looks like that the MySQL delete statements are slowing the system down.
It is not clear what exactly those delete statements are or what is causing those to be slow. That is one of the questions to look into next.
Another thing we want to look into is the tuning of the MySQL database configuration and we also want to get familiar with New Relic.
Do you have any thoughts? Or did you do any performance improvements you did? We can use any help and we will keep posted about our quest for performance.