Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Understanding XHProf: Pinpointing Why Your Site is Slow and How to Fix It

Understanding XHProf: Pinpointing Why Your Site is Slow and How to Fix It

Ezra Gildesgame

April 19, 2014
Tweet

Transcript

  1. Understanding XHProf Pinpointing Why Your Site is Slow and How

    to Fix It Ezra Gildesgame - Acquia @ezrabg Stanford Drupal Camp 2014
  2. XHProf provides information about execution time • Time spent by

    the server to generate page sent to the web browser (or API endpoint) • Also measures memory & CPU usage
  3. XHProf does not measure: • Time to First Byte (TTFB)

    • Page render time (happens in the browser) • Other aspects of front-end performance • For page render time, see Chrome Dev tools, YSlow
  4. Our goal: Reduce page execution time • Improve user experience

    • Improve concurrency and efficient use of server resources.
  5. Avoid speculation: • “Maybe it’s x” • Wasted time on

    fruitless investigation • Wasted time on inappropriate remediations • Vague problem descriptions, “Eg, Views is slow”
  6. Be smart, m’kay? • Tools like Views & Panels empower

    you to do inefficient things but aren’t necessarily bad for performance • Views render & query, Panels pane caches are great tools to improve performance
  7. Example problem statement • “Entity loads are slow because when

    we load entities, we load field X which also loads Y data, which spends Z time in the database. Page A loads 1,000 entities of type X.”
  8. Use XHProf to • Pinpoint the root cause of performance

    problems • Develop a surgical remediation plan
  9. Key UI Elements • # of function calls • Wall

    time (Inclusive/exclusive) • Memory usage • CPU time
  10. CPU Time vs Wall Time • CPU Time: Time spent

    by the CPU • Wall time: Time including disk I/O • CPU time != Wall time? Likely waiting for disk
  11. We may find: • Slow queries • Execute page again

    with Devel query log, use built-in explain feature
  12. What is “excessive” • It depends! Know your app. •

    Maybe you need that data on that request: Make it less expensive to compute • Maybe you don’t need that data: Don’t compute it
  13. We may find: • Excessive calls to watchdog() • Notices

    can slow down your site. • Fix those notices!
  14. Getting started • Brew install xhprof • Install: http://drupal.org/project/xhprof •

    Alternative: https://github.com/ msonnabaum/xhprof-single-file
  15. Avoid dirty runs. • Eliminate menu rebuilds • Disable Devel

    query log • Disable XDebug - Really. • Test as a non-admin (access control is expensive. We want to observe that.)
  16. Know which caches are in place • Views caches (Disable

    Views caches: https:// gist.github.com/msonnabaum/9671947) • Panels Caches • Other caches
  17. “Slow” Define success with specific performance goals • Execution time

    on specific page logged in as specific user under specific conditions • Quantify improvements on a per-page basis
  18. Example: Static Caching in CTools https://drupal.org/node/2049087 • Eliminated ~128,000 calls

    to t() • Reduced memory footprint • Reduced page execution time by 2 seconds • Simple fix
  19. Example: Static caching of node access grants https://drupal.org/comment/8495029 • node_access_grants()

    never changes within a request • Why compute it multiple times within a request?