Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

High Performance Drupal

1,600 views

Published on

"Drupal is always so fast!" ... said no one, ever.

Drupal has a reputation as being a slow CMS, but that reputation is undeserved; there are many small things that impact a Drupal site's performance in sometimes substantial ways. This session will highlight many 'quick wins' that will get your site performing like a champ in no time!

Then we'll take a demonstration site that has many elements of real-world 'slow' Drupal sites, show how to do a quick performance evaluation/triage, and change the site from loading in 4-5 seconds to loading in less than a second, and maxing out at 2 requests per second to a speedy 4,000+ requests per second!

The session will also discuss the importance of a plan, benchmarking, and assumptions when you do performance work on your own Drupal site.

Published in: Software

High Performance Drupal

  1. 1. High Performance Drupal Jeff Geerling Technical Architect, Acqia
  2. 2. geerlingguy • Hosted Apache Solr • Server Check.in • Ansible for DevOps • Technical Architect
  3. 3. "Drupal is SLOW!"
  4. 4. "Drupal is SLOW!"
  5. 5. "It's actually hard to intentionally make Drupal slow." - Me, when creating this presentation
  6. 6. Agenda 1. Process for performance improvement 2. Easy Wins for Drupal performance 3. Live site performance improvement demo
  7. 7. Process • Have a plan: • "Front page should load in < 2 seconds for anonymous users." • "Time to first byte should be < 500ms for anonymous users."
  8. 8. Process • Have a plan: • "Front page should load in < 2 seconds for anonymous users." • "Time to first byte should be < 500ms for anonymous users."
  9. 9. Process • Run benchmarks: • TTFB, Full page load, DOM complete, etc.
  10. 10. Process hard low high easy Performance Improvement Difficulty
  11. 11. Process hard low high easy Performance Improvement Difficulty Good
  12. 12. Process hard low high easy Performance Improvement Difficulty Good Bad
  13. 13. Process hard low high easy Performance Improvement Difficulty Good Bad "m eh"
  14. 14. Process hard low high easy Performance Improvement Difficulty Good Bad "m eh" Focus on this area
  15. 15. Useful Tools • Chrome Developer Tools • Devel, drush • XHProf (and sometimes XDebug) • WebPagetest.org • GTmetrix • Pingdom Website Speed Test • ab / wrk / jmeter
  16. 16. Focus on ROI Focus on fixes that produce order-of-magnitude gains first!
  17. 17. Easy Wins - Drupal • General • KISS: Remove modules, simplify layouts... be ruthless! • Use Boost (if no Varnish/Nginx static cache) • Disable dblog module
  18. 18. Easy Wins - Drupal • Caching • Enable anonymous page cache (default in D8) • Views: use views caching (+ Views cache bully... but not needed in D8!), use Litepager • Use panels, block, entity caching • Watch for cache-breaking elements (e.g. login block + Honeypot, etc.)
  19. 19. Easy Wins - Drupal • On the edge of 'easy' • Use drupal_fast_404() + Fast 404 • Avoid redirects inside Drupal (convenience tradeoff) • Use drush for cron, use Elysia Cron
  20. 20. Easy Wins - Backend • Apache / Nginx • "Use PHP-FPM instead of Apache mod_php" • Not really this simple; more about smart resource allocation • More CPU cores, more RAM
  21. 21. Easy Wins - Backend • PHP • Run version 5.5+ • Make sure OpCache can hold all your code
 (opcache_get_status()) • MySQL • innodb_buffer_size - database in RAM • slow_query_log - watch it!
  22. 22. Easy Wins - Front End • Optimize images (smaller sizes w/ styles, fewer images per page, lazy loading) • Enable CSS/JS Aggregation, consider advagg • Use CloudFlare or another CDN • YSlow/PageSpeed - Fix easy configuration changes (expires, etags, etc.) • Remove external / social widgets and embeds
  23. 23. Easy Wins - Front End • External service integrations are often the #1 or #2 performance burden for front-end page load times. • Social widgets • Embedded media • Ads, tracking • iframe content
  24. 24. Let's Do This Thing! 1. Plan 2. Benchmark 3. Adjust 4. Benchmark again
  25. 25. 1. Plan • Home page should load in <1s for anonymous users over a local network connection • Home page should load in <2s for authenticated users over a local network connection • Assumptions: • Site has mostly anonymous traffic • Site serves a single geographical region, mostly desktop users
  26. 26. 1. Plan • Home page should load in <1s for anonymous users over a local network connection • Home page should load in <2s for authenticated users over a local network connection • Assumptions: • Site has mostly anonymous traffic • Site serves a single geographical region, mostly desktop users Important!
  27. 27. Demo site: http://hp-drupal.dev/ (running on Drupal VM)
  28. 28. 2. Benchmark Chrome Dev Tools: • View > Developer >
 Developer Tools • Option + ⌘ + I (Mac) • Ctrl + Shift + C (Win/Linux) Network tab DOMContentLoaded Load (total time)
  29. 29. 2. Benchmark $ time drush @alias php-eval ' $path="front"; menu_set_active_item($path); menu_execute_active_handler($path, TRUE);' > /dev/null $ wrk -t2 -c4 -d30s http://www.example.com/ $ ab -n 50 -c 2 http://www.example.com/ Test PHP/Drupal alone: Test Backend alone:
  30. 30. 2. Benchmark Benchmark Before After DOMContentLoaded ~1.6s ? Load (Full) ~4.0s ? drush (backend) ~2.0s ? wrk (load test) ~1.75 req/s ?
  31. 31. 3. Adjust Symptom Indication Large BE/FE Δ Slow-loading FE resources Long TTFB* (> 1s) Backend response slow ~2 req/s capacity Site will scale... poorly *TTFB = Time To First Byte
  32. 32. 3. Adjust • Add Caching • Beware lipstick on a pig! • Caches should make what's good, better • Stop the bleeding first • Easy Wins, then harder things like slow queries and code fixes
  33. 33. 4. Benchmark again Benchmark Before After DOMContentLoaded ~1.6s ~0.2s Load (Full) ~4.0s ~0.2s drush (backend) ~2.0s ~0.8s wrk (load test) ~1.75 req/s ~437 req/s
  34. 34. Bonus Round
  35. 35. 4. Benchmark again Benchmark Before After + VARNISH DOMContentLoaded ~1.6s ~0.1s Load (Full) ~4.0s ~0.1s drush (backend) ~2.0s ~ wrk (load test) ~1.75 req/s ~4,000 req/s
  36. 36. Other Considerations • Monitoring: • Uptime (Pingdom, Server Check.in, etc.) • Performance (AppNeta, NewRelic) • Resource usage (Munin, Cacti, Icinga) • Infrastructure - HA, Scalability • UX and performance
  37. 37. Other Resources • High Performance Drupal (O'Reilly) • Drupal VM (optimized LAMP stack) • Ansible for DevOps (infrastructure focus)

×