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

2. Jeff Beeman (jrbeeman)
Erik Webb (erikwebb)
Planning for Performance

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

4. About Erik
• Technical Team Lead
• Focus on Performance,
Infrastructure, and
Scalability
• Joined Acquia in early
2010
• 7+ years with Drupal
• 12+ years with LAMP

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

6. Lessons we won't cover here...
CDNs
Minification
Far-future
expiration
Cache
purging
Client-side
rendering
Profiling

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

8. Top Drupal performance problems

9. This is about planning!

10. 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."

11. Use cases

12. Make your marketing team happy!

13. Define goals

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

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

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

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

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

19. Granularity
The functional differentiation for each cache
item.

20. The number of variations created for a
single cache item.
Cardinality

21. Cache expiration
Period at which cache should be expired.

22. Resources required to rebuild the cache.
Cost to rebuild cache

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

24. Stop talking about Drupal!

25. Now for an example!

34. Use your wireframes!
• Cardinality
• Granularity
• Cache expiration (time vs. action)
• Rebuild cost

36. New tech solves tech problems, not project
problems.

37. Monitoring
Client Monitoring
Application Monitoring
Request Profiling
Metrics/Instrumentation
XHProf
Log Monitoring

38. 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.*

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

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

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

43. Questions?
@doogiemac / @erikwebb
We're hiring!
Evaluate this session:
austin2014.drupal.org/schedule