Upload
ezra-gildesgame
View
228
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
Understanding XHProfPinpointing Why Your Site is Slow and How to Fix It
Ezra Gildesgame - Acquia@ezrabg
Stanford Drupal Camp 2014
The Problem: Slow Websites/Web apps
• Unhappy users leave
• Severs can’t sustain load
Every second counts
• http://blog.kissmetrics.com/loading-time/
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
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
Our goal: Reduce page execution
time
• Improve user experience
• Improve concurrency and efficient use of server resources.
Avoid speculation:
• “Maybe it’s x”
• Wasted time on fruitless investigation
• Wasted time on inappropriate remediations
• Vague problem descriptions, “Eg, Views is slow”
Misconceptions
Misconceptions
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
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.”
Use XHProf to
• Pinpoint the root cause of performance problems
• Develop a surgical remediation plan
Key UI Elements
• # of function calls
• Wall time (Inclusive/exclusive)
• Memory usage
• CPU time
Exclusive/Inclusive
• Exclusive: This function only
• Inclusive: This function and all child functions
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
We may find:
• Function called many times unnecessarily
• Consider a static cache
We may find:
• Slow queries
• Execute page again with Devel query log, use built-in explain feature
We may find:
• Many fast queries that stack up
We may find
We may find
• Queries that are quick to execute but slow to assemble
We may find:
• Excessive entity loads
• Excessive calls to memcache set/get
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
We may find:
• Page-blocking calls (eg, 3rd-party API requests)
• Queue these
We may find:
• Excessive calls to watchdog()
• Notices can slow down your site.
• Fix those notices!
We may find:
• Views/Panels render time - Dig deeper!
We may find:
Getting started
• Brew install xhprof
• Install: http://drupal.org/project/xhprof
• Alternative: https://github.com/msonnabaum/xhprof-single-file
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.)
Know which caches are in place
• Views caches (Disable Views caches: https://gist.github.com/msonnabaum/9671947)
• Panels Caches
• Other caches
Other caches
“ZOMG! The site is slow!”
• ORLY
• Develop a plan to measure and set goals
“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
Example template
Case examples
Example 1
Example: Static Caching in CToolshttps://drupal.org/node/2049087
• Eliminated ~128,000 calls to t()
• Reduced memory footprint
• Reduced page execution time by 2 seconds
• Simple fix
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?
Example: Avoid unnecessary entity loads
https://drupal.org/node/2169099
Optimize node access query building
https://drupal.org/comment/8516319
Questions?