CiviCRM Community Forums (archive)

Democrats.com is an independent community of Democratic Party and progressive activists.  Democrats.com was launched at the 2000 Democratic convention in Los Angeles with a vision to create the leading news and community Web site for the progressive base of the Democratic Party.

Democrats.com has been running CiviCRM since ~2002 when it migrated to Drupal from a custom Cold Fusion CMS.  It now stores over half a million contacts.  The CiviCRM features that the site uses is limited to one address per contact and a few custom fields.  As for customizations, other than the occasional bug fix (I think all of which have been submitted as patches to the issue queue), we have:

- removed all "LOWER" modifiers from search queries.  But I believe that this is now in core.
- use our own custom functions to find a contact by email rather than use the API.  The API in 2.0 was still doing joins to civicrm_contact to find a contact_id given an email.  I believe that this is now also in core.
- make sure to "dupe_check" => FALSE when inserting a new contact.  We use our own email function above to search for dupes before inserting.
- Keep geocoding off, only enable during cron to geocode new/changed contacts.  We also enable when someone saves their profile at user/[uid]/[civicrm-profile]/edit/[civicrm_profile] because we lookup their congressional district via Sunlight when that form is saved.  Still working on tweaking this so that it won't take the site down during a big petition.  A Drupal module integrating CiviCRM and Sunlight is forthcoming (but it'll only be D5 so not much use to the majority of people).
- use CiviCRM hooks to display a few extra tabs on the Contact page to show what activity a Contact has done in other areas of the site (petitions, etc.).  This is not using CiviCRM activities.
- we only use the US states, but we created a special state for [NON-US]
- added an index to the postal code field.  Not sure why I did this.  Now that I see it I think it should be removed.
- removed some indexes that either were redundant or just not useful to this particular site: civicrm_email_is_primary_idx, index_is_billing.
- Here's a big one.  There's a lot of things that integrate somewhat with CiviCRM.  For example we have  a petition system where an email blast goes out, the user clicks a link in their email with a query token on the URL.  They arrive at the petition page and we decode a contact_id from the token.  The form is pre-filled with their contact details.  But we don't query the API directly.  We first see if the contact is stored in the cache, if not then retrieve with the API and store the contact in the cache.  When a contact is edited we use hook_post to remove it from the cache. This is a Drupal cache BTW.  It's a DB cache, not even APC or memcache.

The entire site (except for mass emailing) runs on one dual core opteron with 8GB RAM.  The server is very tunned.  When a popular petition is sent out  there may be 50,000 people that will sign it within a few days and the pages remain loading at a good clip.

A few inner joins vs. a simple query to one table is a big difference when there's several requests per second.  This setup also gives us the option to now move that DB cache table to an object cache like APC or memcache for serious performance gains.