DrupalCon Austin: Planning for Performance
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

DrupalCon Austin: Planning for Performance

on

  • 183 views

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

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

Statistics

Views

Total Views
183
Views on SlideShare
181
Embed Views
2

Actions

Likes
1
Downloads
3
Comments
0

1 Embed 2

https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DrupalCon Austin: Planning for Performance Presentation Transcript

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