performance2

Speed up Drupal

www.wearepropeople.com

Alex Scutaru

Technical Leader, Propeople

http://www.wearepropeople.com/


Content:1. Introduction2. Basic actions 3. Performance problems. Bottlenecks4. Goals5. Drupal performance settings6. Drupal settings, modules7. Optcode caching. APC8. Compression. Logging9. Varnish10. Memcache11. Caching strategy



Introduction:

• Why we need scaling and performance tunning?• Users are not happy with 5 seconds loading time• Site traffic grow and your server is not more capable to fulfill all requests



Basic actions:

• Scale Up - add more memory - upgrade CPU - switch to SSD

• Scale Out - move the database server to a different physical machine - pay attention to network latency - use Apache Solr as a search backend - add more web servers, use a load balancer (hardware and/or Varnish)

• Update PHP to the latest version compatible with your Drupal version• Update Drupal core and contrib modules



Performance problems. Bottlenecks:

• Apache - each process/request use a lot of memory - number of concurrent requests is limited to server memory

• Database - Drupal execute hundreds of queries for each page - table locks and not optimized queries increase page execution time - network latency if database is on different physical machine

• Filesystem - a lot of php files to load for each request - php/apache logs - static files reads



Goals:

• Decrease number of http requests to Apache• Decrease filesystem usage• Less database queries



Drupal performance settings:• Turn on CSS and JS aggregation

- less http requests, less apache child process running on server.• Cache pages for anonymous users

- save generated pages in Drupal cache - save a lot of database and php resources - also improve authenticated users experience indirectly

• Cache blocks - works also for authenticated users

• Adjust cache lifetime• Adjust expiration of cached pages. It is basically the browser cache.

• Use CSS sprites to decrease http requests• Optimize images for web. Pay attention to png (http://tinypng.org/)



Drupal settings, Modules:• Minimize the number of modules you use, review each installed module to find out if you really need it.• Minimize the number of custom modules, group the code in one or couple of modules.• Less modules you load, less memory is used• Disable Database Logging module. Use Syslog module.• Disable Cron. Use crontab to run cron.• Use drush cron instead of wget (drush will run as a cli php script avoiding overhead from apache)• Send emails from cron• Avoid using external http calls during regular page execution. Move it to cron and aggregate data



Optcode caching. APC:

• Avoid the overhead of parsing and compiling source code on each request• Decrease CPU and memory usage• Minimize filesystem usage by configuring APC with apc.stat="1" to skip file check. Require an apache restart after deploying code changes



Compression. Logging:

• Enable file compression by MIME type with mod_deflateAddOutputFilterByType DEFLATE text/* application/javascript application/xjavascript application/rss+xml application/xml

• Fix all code errors/warnings to write less logs• Configure php to ignore notice messages• Minimize the apache access log by ignoring requests to static contentsetenvIf Request_URI ".(jpg|jpeg|png|css|gif|ico|js)$" dontlogCustomLog /var/log/httpdaccess.log combined env=!dontlog



Varnish:

• Use Varnish to cache pages and static content for anonymous users• Configure Apache to listen to port 8080 and Varnish on 80• Varnish will store generated pages in memory• Use devnull module to avoid double caching for cache_page• Considerably decrease the number of apache processes. Saving CPU and memory• Cache static content for authenticated usersif (req.url ~ "\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?[az09]+)?$") { unset req.http.Cookie;}

• If you have same content to display for some pages for authenticated users you can configure Varnish and Drupal to cache these pages



Memcache:

• Use Memcache as a default caching engine for Drupal - get rid of database writes/reads to _cache tables - much faster than database

• Use for session handling• Use for Locking (expensive write queries)• Separate memcache daemon for sessions• Set Locking to use the same daemon as sessions



Caching strategy:

• Cache as much elements as possible• Analyze each panel, minipanel, view to find out if you can cache them• Using content access restriction modules like OG will disable block caching. Put the content in minipanels, cache it and display as a block• Cache menus using the same rule if you have menu access restrictions. They use a lot of database queries to check permissions



Thanks!

Questions?




drupal.org/marketplace/propeopletwitter.com/propeoplefacebook.com/propeople

Strategy, Design & Technology to create value and reach your goals.


performance2

Documents