High Performance Drupal
5 likes1,993 views
The document provides a comprehensive guide to improving Drupal performance, emphasizing the importance of planning, benchmarking, and making systematic adjustments. It outlines easy wins for optimization, including caching strategies, backend improvements, and frontend optimizations. The content also highlights the necessity of monitoring resources and maintaining user experience while aiming for specific loading time targets.
High Performance Drupal
- 1. High Performance Drupal Jeff Geerling Technical Architect, Acqia
- 2. geerlingguy • Hosted Apache Solr • Server Check.in • Ansible for DevOps • Technical Architect
- 5. "It's actually hard to intentionally make Drupal slow." - Me, when creating this presentation
- 6. Agenda 1. Process for performance improvement 2. Easy Wins for Drupal performance 3. Live site performance improvement demo
- 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. 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. Process • Run benchmarks: • TTFB, Full page load, DOM complete, etc.
- 15. Useful Tools • Chrome Developer Tools • Devel, drush • XHProf (and sometimes XDebug) • WebPagetest.org • GTmetrix • Pingdom Website Speed Test • ab / wrk / jmeter
- 16. Focus on ROI Focus on fixes that produce order-of-magnitude gains first!
- 17. Easy Wins - Drupal • General • KISS: Remove modules, simplify layouts... be ruthless! • Use Boost (if no Varnish/Nginx static cache) • Disable dblog module
- 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. 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. 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. 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. 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. 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. Let's Do This Thing! 1. Plan 2. Benchmark 3. Adjust 4. Benchmark again
- 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. 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. Demo site: http://hp-drupal.dev/ (running on Drupal VM)
- 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. 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. 2. Benchmark Benchmark Before After DOMContentLoaded ~1.6s ? Load (Full) ~4.0s ? drush (backend) ~2.0s ? wrk (load test) ~1.75 req/s ?
- 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. 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. 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. Bonus Round
- 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. Other Considerations • Monitoring: • Uptime (Pingdom, Server Check.in, etc.) • Performance (AppNeta, NewRelic) • Resource usage (Munin, Cacti, Icinga) • Infrastructure - HA, Scalability • UX and performance
- 37. Other Resources • High Performance Drupal (O'Reilly) • Drupal VM (optimized LAMP stack) • Ansible for DevOps (infrastructure focus)