High Performance Drupal Sites


Published on

High Performance Drupal Sites lectures was delivered by Rami Järvinen of Exove Oy

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

High Performance Drupal Sites

  1. 1. High performance Drupal sitesDrupalCamp Helsinki 27.9.2011Rami Järvinen, Exove Oy
  2. 2. AgendaAbout Exove and myselfCachingScalingOptimizing
  3. 3. Exove enables companies toconduct better business on the Internetthrough best-of-breed personnel and solutions
  4. 4. We design and implement beautiful, functional, and business-driven solutions
  5. 5. About myself, Rami JärvinenSenior developer at ExoveDrupal experience from 2006. Been involved with awide variety of different site projects.
  6. 6. Drupal is slowWhy?
  7. 7. Drupal is slowWhy?•  Page rendering
  8. 8. Drupal is slowWhy?•  Page rendering•  Database queries
  9. 9. Drupal is slowWhy?•  Page rendering•  Database queries•  Programmers
  10. 10. Drupal is slowWhy? Solution•  Page rendering •  Caching•  Database queries •  Caching / Optimizing•  Programmers •  ???
  11. 11. Boosting up the performance•  Drupal’s internal architecture •  Single-controller •  Loads a lot of code on every pageload •  Tends to be slower than a pure MVC-model•  Caching •  Minimize the CPU usage •  Minimize the amount of SQL queries •  Ultimately – avoid running Drupal’s bootstrap
  12. 12. Caching layers•  MySQL query cache•  PHP opcode cache•  Drupal internal caching•  HTTP cache (reverse proxy)•  Browser cache•  HTML 5: Client-side storage
  13. 13. Caching layers – PHP opcode cache•  Alternative PHP Cache (APC)•  PHP code is compiled every time it is read•  APC caches the compiled bytecode•  Parsing and compiling PHP code is not needed, if thebytecode is in the cache•  Works generally everywhere and gives a major boostin performance
  14. 14. Caching layers – Drupal internal caching•  Block cache •  Global / per role / per user•  Page cache •  For anonymous users•  Code level caching•  Contrib modules •  Boost •  Memcache API and Integration
  15. 15. Cache layers – Code level•  1st rule of caching and optimization: Never dosomething time consuming twice if you can hold ontothe results and re-use them•  Static variables for storing data within a function forthe duration of a single page load. •  Use drupal_static() to utilize central static variable storage•  Using cache_set() and cache_get() functions forcaching data more permanently.
  16. 16. Caching layers - Boost•  Generated page HTML is saved as a static file •  Page loads never touch the database•  For anonymous traffic and sites with a little dynamiccontent•  Easy to set up even on a cheap web hotel •  Enable the module, modify .htaccess and you’re done•  Highly configurable•  For not yet cached content, serves the page first andsaves HTML after that•  Inbuilt crawler for cache warm-up
  17. 17. Caching layers – Memcached•  High-performance, distributed memory objectcaching system•  In-memory key-value store for small chunks ofarbitrary data•  Drop-in replacement for changing Drupal cachebackend •  Instead of saving cached data to DB, it goes to memcached •  High-traffic sites really need to save the cache to memory•  Also for session data etc.
  18. 18. Caching layers – Reverse proxy•  Varnish Cache•  Designed from the ground up as an HTTP accelerator•  Stores data in virtual memory•  Configurable with VCL (Varnish ConfigurationLanguage)•  Edge Side Includes (ESI) <esi include=“/esi/some_content” />•  ESI integration module •  Block template will be changed to instruct Varnish to get block content from e.g. http://example.com/esi/block/xxxxxx
  19. 19. Cache Control module•  An alternative to ESI•  Cheaper way to display user specific content•  How it works •  For all users, we load the page with anonymous content hidden under a throbber •  JS then checks if the user is logged in (w/ cookie) and (for anonymous users) set the anonymous content visible •  For logged in users (after JS has checked the login status), it makes a single request to the backend to get the user-specific data for the page•  http://drupal.org/node/1155312
  20. 20. Scaling Drupal•  MySQL •  High-performance configurations. There are many good base configs available – start with them •  Dedicated server •  Master-slave setup •  Direct some of the SQL queries to slave•  Files •  Serve static files with Nginx or lighttpd •  Or use reverse proxy to cache them •  CDN if there’s a massive library of static content•  Scaling by buying more hardware?
  21. 21. Hardware stack example Linux, Apache PHP Server 1 memcached MySQL master
  22. 22. Hardware stack example Linux, Apache PHP MySQL master Front R/W server 1 MySQL memcached server 1
  23. 23. Hardware stack example memcached MySQL server 2 HTTP Front cache 1 server 2 Linux, MySQL Varnish slave Load Apache PHP R balancer Front Linux, R/W server Varnish Apache PHP MySQL master HTTP Front cache 2 server 1 MySQL memcached server 1
  24. 24. Optimizing•  Profiling •  Xdebug, XHProf and similar profiling tool to see what actually happens during a page load •  Devel module to print a summary of all database queries executed for page request, including how many times each query was executed and how long each query took•  SQL bottlenecks •  Unnecessary repeating of same queries •  Missing indexes •  Temporary tables and filesort •  Use EXPLAIN to find out how MySQL executes your monster query •  Table locking if using MyISAM engine in MySQL
  25. 25. • “Is there a lot of logged in users or are most of themanonymous?” •  This pretty much defines what kind of caching strategies can be applied•  “What kind of things my hosting environment allowsme to do?”•  There’s no single best solution
  26. 26. Thank you  Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.