High Performance Drupal Sites
Upcoming SlideShare
Loading in...5
×
 

High Performance Drupal Sites

on

  • 2,778 views

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

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

Statistics

Views

Total Views
2,778
Views on SlideShare
2,778
Embed Views
0

Actions

Likes
4
Downloads
40
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

High Performance Drupal Sites Presentation Transcript

  • 1. High performance Drupal sitesDrupalCamp Helsinki 27.9.2011Rami Järvinen, Exove Oy
  • 2. AgendaAbout Exove and myselfCachingScalingOptimizing
  • 3. Exove enables companies toconduct better business on the Internetthrough best-of-breed personnel and solutions
  • 4. We design and implement beautiful, functional, and business-driven solutions
  • 5. About myself, Rami JärvinenSenior developer at ExoveDrupal experience from 2006. Been involved with awide variety of different site projects.
  • 6. Drupal is slowWhy?
  • 7. Drupal is slowWhy?•  Page rendering
  • 8. Drupal is slowWhy?•  Page rendering•  Database queries
  • 9. Drupal is slowWhy?•  Page rendering•  Database queries•  Programmers
  • 10. Drupal is slowWhy? 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 thebytecode is in the cache•  Works generally everywhere and gives a major boostin 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 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. 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. 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. 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. 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 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. Thank you  Questions?