High Performance Drupal

Jeff GeerlingTechnical Architect, Acqia

geerlingguy

• Hosted Apache Solr • Server Check.in • Ansible for DevOps

• Technical Architect

"Drupal is SLOW!"

"Drupal is SLOW!"

"It's actually hard to intentionally make Drupal slow."

- Me, when creating this presentation

Agenda

1. Process for performance improvement

2. Easy Wins for Drupal performance

3. Live site performance improvement demo

Process• Have a plan:

• "Front page should load in < 2 seconds for anonymous users."

• "Time to first byte should be < 500ms for anonymous users."

Process• Have a plan:

• "Front page should load in < 2 seconds for anonymous users."

• "Time to first byte should be < 500ms for anonymous users."

Process• Run benchmarks:

• TTFB, Full page load, DOM complete, etc.

Process

hard

low

high

easy

PerformanceImprovement

Difficulty

Process

hard

low

high

easy

PerformanceImprovement

Difficulty

Good

Process

hard

low

high

easy

PerformanceImprovement

Difficulty

Good

Bad

Process

hard

low

high

easy

PerformanceImprovement

Difficulty

Good

Bad

"meh"

Process

hard

low

high

easy

PerformanceImprovement

Difficulty

Good

Bad

"meh"

Focus on this area

Useful Tools• Chrome Developer Tools

• Devel, drush

• XHProf (and sometimes XDebug)

• WebPagetest.org

• GTmetrix

• Pingdom Website Speed Test

• ab / wrk / jmeter

Focus on ROI

Focus on fixes that produce order-of-magnitude gains first!

Easy Wins - Drupal

• General

• KISS: Remove modules, simplify layouts... be ruthless!

• Use Boost (if no Varnish/Nginx static cache)

• Disable dblog module

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.)

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

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

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!

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

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

Let's Do This Thing!1. Plan

2. Benchmark

3. Adjust

4. Benchmark again

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

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 usersIm

porta

nt!

Demo site: http://hp-drupal.dev/ (running on Drupal VM)

2. Benchmark

Chrome Dev Tools: • View > Developer >

Developer Tools • Option + ⌘ + I (Mac) • Ctrl + Shift + C (Win/Linux)

Network tab

DOMContentLoaded Load (total time)

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:

2. BenchmarkBenchmark Before After

DOMContentLoaded ~1.6s ?

Load (Full) ~4.0s ?

drush (backend) ~2.0s ?

wrk (load test) ~1.75 req/s ?

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

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

4. Benchmark againBenchmark 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

Bonus Round

4. Benchmark againBenchmark 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

Other Considerations• Monitoring:

• Uptime (Pingdom, Server Check.in, etc.)

• Performance (AppNeta, NewRelic)

• Resource usage (Munin, Cacti, Icinga)

• Infrastructure - HA, Scalability

• UX and performance

Other Resources

• High Performance Drupal (O'Reilly)

• Drupal VM (optimized LAMP stack)

• Ansible for DevOps (infrastructure focus)