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 wit...
About Erik
• Technical Team Lead
• Focus on Performance,
Infrastructure, and
Scalability
• Joined Acquia in early
2010
• 7...
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.
• T...
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...
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...
Defining goals: examples
• Bad: The homepage should load in 3s or less.
• Good: The homepage should be delivered to
anonym...
Setting goals
Page delivery (TTFB) Page render
User type Page type Median Maximum Median Maximum
Anonymous
<Aggregate>
Hom...
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 ...
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.
• ...
You know what they say about
assumptions...
• NEVER assume that the problem is in
custom code.
• NEVER assume a well-used ...
Catch it early
• Develop with data on par with production:
Data volume and values matter!
• Ensure diagnostic tools are av...
Summary
• Planning for performance means setting
goals and defining strategies.
• Establish a cache strategy for page
comp...
Questions?
@doogiemac / @erikwebb
We're hiring!
Evaluate this session:
austin2014.drupal.org/schedule
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
DrupalCon Austin: Planning for Performance
Upcoming SlideShare
Loading in …5
×

DrupalCon Austin: Planning for Performance

727 views

Published on

Jeff Beeman and Erik Webb from Acquia's Professional Services talk about effectively planning for performance.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
727
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

DrupalCon Austin: Planning for Performance

  1. 1. Jeff Beeman (jrbeeman) Erik Webb (erikwebb) Planning for Performance
  2. 2. 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
  3. 3. About Erik • Technical Team Lead • Focus on Performance, Infrastructure, and Scalability • Joined Acquia in early 2010 • 7+ years with Drupal • 12+ years with LAMP
  4. 4. https://portland2013.drupal.org/node/2208
  5. 5. Lessons we won't cover here... CDNs Minification Far-future expiration Cache purging Client-side rendering Profiling
  6. 6. 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.
  7. 7. Top Drupal performance problems
  8. 8. This is about planning!
  9. 9. 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."
  10. 10. Use cases
  11. 11. Make your marketing team happy!
  12. 12. Define goals
  13. 13. Defining goals • Context is critical when defining goals • User type: Anonymous vs. authenticated • Page type: Homepage vs. article page
  14. 14. 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.
  15. 15. Setting goals Page 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
  16. 16. Caching isn't just "on" or "off"
  17. 17. Cache effectiveness • Cardinality • Granularity • Cache expiration (time vs. action) • Rebuild cost
  18. 18. Granularity The functional differentiation for each cache item.
  19. 19. The number of variations created for a single cache item. Cardinality
  20. 20. Cache expiration Period at which cache should be expired.
  21. 21. Resources required to rebuild the cache. Cost to rebuild cache
  22. 22. 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.
  23. 23. Stop talking about Drupal!
  24. 24. Now for an example!
  25. 25. Use your wireframes! • Cardinality • Granularity • Cache expiration (time vs. action) • Rebuild cost
  26. 26. New tech solves tech problems, not project problems.
  27. 27. Monitoring Client Monitoring Application Monitoring Request Profiling Metrics/Instrumentation XHProf Log Monitoring
  28. 28. 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.*
  29. 29. 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.
  30. 30. 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.
  31. 31. 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.
  32. 32. Questions? @doogiemac / @erikwebb We're hiring! Evaluate this session: austin2014.drupal.org/schedule

×