Making it Happen a bit faster (performance and your Civi Site)
Slow pages are annoying and they can cost $$$. But improving performance often means re-writing chunks of code and is often expensive. Bad performance hurts us all. So the question is how can we improve it.
The main mechanism we have used in the community so far for banding together to fund these things is the MIH - the tricky thing for performance is framing the MIH in a useful way.
There are some specific areas of known slowness in CiviCRM which it would be great to address and we could raise specific MIH for. Some that I am aware of are:
- Too many search fields (e.g contribution dashboard) - the query that runs when gathering data for screens like the contribution dashboard gathers a bunch of fields that aren't required for that purpose. We have found that on a medium sized database (80,000 contributions) a temp tables of over a GB of RAM is created (we know this because the temp directory was 1GB). By removing fields like 'product' from those returned we got past the problem. The estimate I have on this is about 15 hours which seems like a great win
- Activity searches - searches involving activities are slower that they need to be because of the table structure. Some time ago we agreed a re-structure plan for these - about 50 hours
- ACLs - Users whose permissions are limited in some way by an ACL hit a piece of code that is pretty sluggish. The current acl cache can be slow to rebuild - and apparently in some (extreme) cases people can actually access things they shouldn't in the meantime! Generally this is a performance hit for anyone who uses ACLs. The approach for tackling this seems to be known and has been estimated at about 20 hours.
- Searches involving joins on option values. In some specific queries we were seeing more then ten-fold improvements by eliminating option value joins. The site I was seeing this on was 3.4 quick search (with prefix id being the offending field)
- Cases where the database is being queried rather than using constants.
The last two of these are a series of small fixes rather than a big one - which leads to my thinking that performance is not a project - it's an ongoing maintenance task. At Fuzion we do regularly submit fixes and improvements to the core code - but we find that it's extremely difficult to make performance improvements within our normal client business. Performance really does matter and we do have to put up with complaints at times. It seems to me that the best way for us and other Consultants/ significant users of CiviCRM to get ongoing improvements in performance and code quality is to commit to a monthly contribution. In our case we are thinking $50 per month each (NZD sorry). If we can get another 20 people / organisations to put in, say, $20 per month we have $6,000 a year - not really enough - but enough to start chipping away at some of the problems.