High Performance Drupal Sites
•
4 likes•2,230 views
This document discusses strategies for improving the performance of Drupal sites, including caching at various levels (PHP opcode, Drupal internal, reverse proxy), using modules like Boost and Memcached, optimizing database and hardware configurations, and profiling code to identify bottlenecks. Specific techniques mentioned include leveraging caching, optimizing SQL queries, using master-slave databases, serving static files from fast servers, scaling out hardware, and profiling with tools like Xdebug to optimize page loads.
Report
Share
High Performance Drupal Sites
- 1. High performance Drupal sites DrupalCamp Helsinki 27.9.2011 Rami Järvinen, Exove Oy
- 2. Agenda About Exove and myself Caching Scaling Optimizing
- 3. Exove enables companies to conduct better business on the Internet through best-of-breed personnel and solutions
- 4. We design and implement beautiful, functional, and business-driven solutions
- 5. About myself, Rami Järvinen Senior developer at Exove Drupal experience from 2006. Been involved with a wide variety of different site projects.
- 7. Drupal is slow Why? • Page rendering
- 8. Drupal is slow Why? • Page rendering • Database queries
- 9. Drupal is slow Why? • Page rendering • Database queries • Programmers
- 10. Drupal is slow Why? Solution • Page rendering • Caching • Database queries • Caching / Optimizing • Programmers • ???
- 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. Caching layers • MySQL query cache • PHP opcode cache • Drupal internal caching • HTTP cache (reverse proxy) • Browser cache • HTML 5: Client-side storage
- 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 the bytecode is in the cache • Works generally everywhere and gives a major boost in performance
- 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. Cache layers – Code level • 1st rule of caching and optimization: Never do something time consuming twice if you can hold onto the results and re-use them • Static variables for storing data within a function for the duration of a single page load. • Use drupal_static() to utilize central static variable storage • Using cache_set() and cache_get() functions for caching data more permanently.
- 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 dynamic content • 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 and saves HTML after that • Inbuilt crawler for cache warm-up
- 17. Caching layers – Memcached • High-performance, distributed memory object caching system • In-memory key-value store for small chunks of arbitrary data • Drop-in replacement for changing Drupal cache backend • 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. Caching layers – Reverse proxy • Varnish Cache • Designed from the ground up as an HTTP accelerator • Stores data in virtual memory • Configurable with VCL (Varnish Configuration Language) • 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. 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. 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. Hardware stack example Linux, Apache PHP Server 1 memcached MySQL master
- 22. Hardware stack example Linux, Apache PHP MySQL master Front R/W server 1 MySQL memcached server 1
- 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. 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. • “Is there a lot of logged in users or are most of them anonymous?” • This pretty much defines what kind of caching strategies can be applied • “What kind of things my hosting environment allows me to do?” • There’s no single best solution