Date post: | 16-Jul-2015 |
Category: |
Technology |
Upload: | jeff-beeman |
View: | 294 times |
Download: | 0 times |
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