GROWING AND SUSTAINING RELATIONSHIPS

GROWING AND SUSTAINING RELATIONSHIPS
Close
Hans Idink

Implementator, Developer

Orgis

http://www.orgis.com

CiviCRM has a key value for the Organisations I support with software.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Alex Jofra

Developer

ixiam

It's all about community. I love the CiviCRM philosophy and in IXIAM, we are trying to expand the catalan speaking community in Catalunya
GROWING AND SUSTAINING RELATIONSHIPS
Close
Rachel Daniell

end-user, implementor

consulting/multi

CiviCRM provides a vital tool whereby nonprofits and other social projects can implement strong contact-relationship management capabilities without high monthly fees. It also provides the integration and customization capabilities necessary to make such software useful in the complex, lived reality of doing social engagement work. Plus it continues to build the open source toolset made available to the Commons and grow the common good.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Sylvain Boissel

Implementor, End-user

Wikimédia France

https://dons.wikimedia.fr

CiviCRM is very helpful for us to manage memberships and donations. As one of the biggest users in France, we would like to help building an active French-speaking community.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Ruben Pineda

Developer, Implementor

IXIAM

http://ixiam.com/

I'm spent a lot of time in project of civicrm and i think that i can contribuite in bugs and development. I see that this weekend is "Bug Smithing Weekend", I will try to collaborate.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Linus Widborg

Administrator

Responsive Development Tecnologies

http://www.responsive.se

We use CiviCrm to keep track of our customers and to administer our seminars and conferences.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Katy Jockelson

Implementor, administrator

Third Sector Design

http://thirdsectordesign.org

We work with non-profits to help them use and understand Civi. It's such an important tool for these organisations and it's great to see people using it in different and interesting ways. Using and working with Civi is made so much more fun and useful by the enthusiastic and talented community surrounding it.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Joshua Walker

Developer / Contributor

Drastik by Design

http://drastikbydesign.com

CiviCRM has one of the best open source communities out there. It's always a blessing when I get the opportunity to do my next project in CiviCRM.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Donald Lobo

Implementor, Developer

CiviCRM LLC

http://civicrm.org

Still thinking of a deep deep quote. Basically:

It is super important for non-profits, advocacy and related groups to take charge of their destiny. Having control of your data is a good start. The crowd-sourced nature of an open source project in so in line with the co-operation and principles of most non-profits

CiviCRM is a project that strives to make the above possible. It is FREE as in kittens.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Kurund Jalmi

Developer, Implementor

Web Access India Pvt. Ltd.

http://webaccessglobal.com

I have been part of CiviCRM project from the beginning and feels great to see how it has grown over the years.
I am glad to be associated with such a wonderful open source project and an awesome community around it.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Carlos Capote Pérez-Andreu

Administrator, Developer

Amnistía Internacional España

http://www.es.amnesty.org

CiviCRM helps us to unify the management of different databases (volunteers, members, etc) allowing us to keep control over our data.
GROWING AND SUSTAINING RELATIONSHIPS
Close
Eileen McNaughton

Developer and End-user

Fuzion

http://fuzion.co.nz

CiviCRM has one of the most active and friendliest communities I have come across. From initial tentative forum posts I was encouraged into engaging more actively through IRC and directly with other groups & individuals and am now happy to count many community members as friends. I recently found an article on the web that said if you post a question about CiviCRM anywhere on the web Lobo will post an answer within a few hours. It often feels like that is true.

One of the most valuable way in which the community supports me is by allowing me to bounce my ideas around and often someone is able to suggest an approach which is better than mine.

You are here

Home » Blogs » Eileen's blog

Making it Happen a bit faster (performance and your Civi Site)

Submitted by Eileen on July 28, 2012 - 09:17

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:

 

  1. 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
  2.  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
  3.  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.
  4. 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)
  5. 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.

 

So, I am launching 2 pages - an MIH for the ACL groups & one for an ongoing performance and code maintenance fund.

 

Comments

Submitted by lcdweb on July 30, 2012 - 07:18

CiviCase related queries are also a significant performance issue. The case queries join with activities and relationships and become quite nightmarish.

I think the plan to have an ongoing maintenance fund is great. But many of the performance weaknesses are found in very specific areas/ways and with live systems stressing a particular area of the system -- so it seems like we should also be working to identify those pain points which seem to be in need of evaluation.

Submitted by Eileen on July 30, 2012 - 14:29

Yes, we should find a place to start to come up with a bit of a list. I had an idea that with the performance fund we could try PCPs - where people could effectively 'vote' for which bugs get high on the list..

I did identify the activity queries as one that we need to tackle. But others on your radar - ideally we should either on the WIKI or JIRA or? flesh them out.

Submitted by fen on August 27, 2012 - 07:33

CivicActions has been using CiviCRM with some of our non-profit clients for years and we have always been happy with the level of support available from the community.  In particular, Eileen has done wonders with the API, test framework and generally supporting the project to become more solid from release to release, which is something every developer and user of this package benefits from.  Thank you!

We are pleased to support the Ongoing Performance improvements and code maintenance MIH that Eileen has suggested and will continue to do what we can to support the project in future releases. (I'd also like to see smart groups optimisation included in the mix!)

Url: 

http://civicactions.com/team/fen_labalme

Submitted by adixon on October 5, 2012 - 05:38

This probably goes without saying, but here goes anyway: it seems to me that most of what you've described above are the result of pushing out new features too quickly. I can certainly understand there's always a tradeoff, but my experience of CiviCRM is that new features get pushed forward and out the door too quickly, resulting in extra code that's not really useful at any scale - the ACL is probably a good example of a scary big complex chunk of code that isn't reliable or scalable enough to use in any useful production environment [imho].

I know this is also not an original observation and that it's an ongoing discussion, but I do think that any initiative for an ongoing maintenance and peformance initiative needs to be integrated into the whole code development process - i.e. before any new features come out in the core code, it needs to be examined from a scalability and maintenance perspective before being included in a release. Now that the new extensions architecture seems to be stabiliizing, maybe that's a good way of allowing early adopters (and funders of new initiatives!) to get their code working and available, but still keep it separate from the core code until it's been more thorougly production tested - kind of like Drupal's process of how many modules start of as contributed modules and only move to core later.

Url: 

http://blackflysolutions.ca/

Submitted by lobo on October 5, 2012 - 17:17

 

I do agree with extensions that folks can package and ship things seperate from the release cycle, which will slow down the number of new features / release. Not a bad thing

ACL's have been around since the 1.x series, and you can get it to scale quite nicely if you implement your own acl's via hooks.

However while having constraints like "the code should scale" is good in theory, a few issue arise:

  • what does scale mean: 10K contacts, 100K, 1 m?, 10 m?
  • However most orgs that use Civi are less than 10K (if i had to guess)
  • what type of hardware and architecture? who'll provide, support and pay for this infrastructure?
  • Not too many organizations at the high end of the scale, which means a lot of code contributed will not scale to those orgs? does that mean we should not incorporate it?
  • There are a couple of bottlenecks within Civi that we know of already (ACL's for multisite, activity etc), but so far very few if no takers to help scale them. but the above are quite useful as is now :)

lobo

 

Url: 

http://civicrm.org/