In this wiki page I'd like to collect scaling and performance problems and solutions for CiviCRM. This is a continuation of the Scaling and Peformance session of CiviCon London 2011

Questions

1. imports
2. exports
3. Mailings / blacklists
4. Speed of website
5. Dashlet draining the server - 
6. autocomplete taking too long (long queries, timeout of search being fired)
7. dedupe process taking too long
8. temp tables fill the database
9. php as CGI is slow with civicrm

Answers

1. imports
   • adapt php configuration: max-execution-time, php-memory-size
   • you can not use csv import but SQL Query
   • change mysql packet size when you have error: Mysql is gone away
   • switch off geocoding!
   • turn off US postal integration
   • look at drupal module hooks. See if they can be switched off
   • switch off dedupe options or change dedupe method based on import contents
   • use amazon RDS as mysql
2. Exports
   • see also: imports
3. Mailings / blacklists
   • external SMTP provider (CiviSMTP, Sendgrid, Socket Labs)
   • consider alternative mailer backends (API driven - Campaign Monitor, Mailchimp?)
   • lobo has tested recently & saw big performance difference using CLI vs HTTP
   • set the batch limit : 3000-5000 is reasonable
   • batch limit and job size should match if large mailouts (2000,2000) + minutely cronjob
4. Speed of website
   • add memcache 
   • drupal: css, js compression enabled
   • apache: mod_expires and mod_deflate enabled
5. Dashlet draining the server - 
6. autocomplete taking too long (long queries, timeout of search being fired)
7. dedupe process taking too long
   •  limit dedupe to a group
   • play around with the dedupe rules, as few fields as possible (especially during import)
8. temp tables fill the database
   • use ACL
9. php as CGI is slow with civicrm
   • use other hosting provider, CGI is not advisable