Three weeks ago I wrote about our quest for performance at the Socialist party. This week we had a follow up sprint and I want to thank you for all the comments on that blog.
During this sprint we have been looking into the direction of the amount of groups (+/- 2.700) and whether the amount of groups slowed down the system. We developed a script for deleting a set of groups from all database tables and we deleted around 2.400 groups from the system and we saw that this had an positive impact on the performance.
Before deleting the groups adding a new group took around 14 seconds. After removing 2.400 groups, adding a new group took around 3 seconds. So that gave us a direction in which we could look for a solution.
We also looked what would happened when we delete all contacts who have not a membership from the database and that also had a positive impact but not as huge as the reducing the amount of groups. The reason we looked into this is that around 200.000 contacts in the system are not members but sympathizers for a specific campaign.
We also had one experienced database guy (who mainly knows Postgres) looking into database tuning; at the moment we don’t know what the outcome is of his inspection.
From what we have discover by reducing the groups we have two paths to follow:

Actually reducing the amount of groups in the system

Developing an extension which does functional the same thing as groups but with a better structure underneath and developed with preformance in mind. (no civicrm_group_contact_cache; no need for nesting with multiple parents; no need for smart groups).
Both paths are going to be discussed at the socialist party and in two weeks we have another sprint in which we hope to continue the performance improvements.
 
  Drupal maintenance support plans
Source: New feed