drupalcon austin: planning for performance

Jeff Beeman (jrbeeman)Erik Webb (erikwebb)

Planning for Performance

About Jeff

• Technical Team Lead

• Focus on Architecture, Deployment, Delivery

• Joined Acquia in late 2010

• 9+ years with Drupal

• Lead architect on many large-scale Drupal projects

About Erik

• Technical Team Lead

• Focus on Performance, Infrastructure, and Scalability

• Joined Acquia in early 2010

• 7+ years with Drupal

• 12+ years with LAMP

https://portland2013.drupal.org/node/2208

Lessons we won't cover here...

CDNs

Minification

Far-future expiration

Cache purging

Client-side rendering

Profiling

Lessons we will cover here...

• Don't rely on intuition: Learn how to measure, assess, and respond based on real data.

• Tools only solve problems you know about.

• By the time you're "tuning," it may be too late.

Top Drupal performance problems

This is about planning!

Why can't we just use X…?

• Deadlines and delivery don't often come with a second chance.

• Gather data first, then choose to optimize.

• Bad architecture cannot be "tuned."

Use cases

Make your marketing team happy!

Define goals

Defining goals

• Context is critical when defining goals• User type: Anonymous vs. authenticated• Page type: Homepage vs. article page

Defining goals: examples

• Bad: The homepage should load in 3s or less.

• Good: The homepage should be delivered to anonymous users within 500ms and fully render within 3s.

• Bad: Any single page should never take longer than 2s to fully load.

• Good: Any single page should fully render to users within 2s for 99% of requests.

Setting goalsPage delivery (TTFB) Page render

User type Page type Median Maximum Median Maximum

Anonymous

<Aggregate>

Homepage

User profile

Article page

Static page

Authenticated

<Aggregate>

Homepage

User login

My profile

Post content

Logout

Caching isn't just "on" or "off"

Cache effectiveness

• Cardinality• Granularity• Cache expiration (time vs. action)• Rebuild cost

Granularity

The functional differentiation for each cache item.

The number of variations created for a single cache item.

Cardinality

Cache expiration

Period at which cache should be expired.

Resources required to rebuild the cache.

Cost to rebuild cache

Strategic decisions

• This is about establishing a cache strategy.

• Not every architecture supports the same performance plan.

• These are not just technical choices.• Should be driven by stakeholders, not

just developers.

Stop talking about Drupal!

Now for an example!

Use your wireframes!

• Cardinality• Granularity• Cache expiration (time vs. action)• Rebuild cost

New tech solves tech problems, not project problems.

Monitoring

Client Monitoring

Application Monitoring

Request Profiling

Metrics/Instrumentation

XHProf

Log Monitoring

You know what they say about assumptions...• NEVER assume a warm cache, unless

your deployment makes that always true.• NEVER assume your caching layer is

persistent (even when it is).• NEVER assume performance will be solid

because of "good architecture."• NEVER assume all features can be

implemented in a performant way.*

You know what they say about assumptions...• NEVER assume that the problem is in

custom code.• NEVER assume a well-used module is a

well-performing one.

Catch it early

• Develop with data on par with production: Data volume and values matter!

• Ensure diagnostic tools are available locally for devs.

• Hold all devs accountable for performance.

• Don't jump to conclusions without data.

Summary

• Planning for performance means setting goals and defining strategies.

• Establish a cache strategy for page components: Cardinality, granularity, cache expiration, rebuild cost.

• Data matters: Don't make decisions or assumptions without it.

Questions?

@doogiemac / @erikwebb

We're hiring!

Evaluate this session: austin2014.drupal.org/schedule