Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Understanding XHProf: Pinpointing Why Your Site is Slow and How to Fix It
Search
Ezra Gildesgame
April 19, 2014
Programming
0
180
Understanding XHProf: Pinpointing Why Your Site is Slow and How to Fix It
Ezra Gildesgame
April 19, 2014
Tweet
Share
Other Decks in Programming
See All in Programming
TCAの Shared Stateって どういう仕組みになってんの?
yimajo
0
330
とにかくHTTP3をライトニングに話す / Anyway, I'll talk to Lightning about HTTP3.
seike460
PRO
0
120
Swiftの型推論を学ぼう | Let's Learn About Type Inference in Swift
omochi
2
790
RubyVM を PHP で実装する 〜Hello World を出力するまで〜
memory1994
PRO
1
490
脱・初心者!脱・マネコン!AWS CDKを使ってみませんか!?
har1101
0
180
Introduction for Open Source Swift Workshop
giginet
PRO
0
290
Open Source Swiftc Workshop
kitasuke
1
290
プロンプトエンジニアリング入門
tomokusaba
2
990
Honoとhtmx
yusukebe
6
1.2k
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
2
540
htmx is fun!
codehex
2
190
もうすぐ新年度、Babylon.jsがお勧めな3個の理由
hideg
0
170
Featured
See All Featured
Designing Experiences People Love
moore
135
23k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Scaling GitHub
holman
456
140k
The Cult of Friendly URLs
andyhume
73
5.6k
Web development in the modern age
philhawksworth
201
10k
Unsuck your backbone
ammeep
661
56k
A Philosophy of Restraint
colly
195
15k
Writing Fast Ruby
sferik
619
59k
Building Adaptive Systems
keathley
29
1.8k
The Art of Programming - Codeland 2020
erikaheidi
40
12k
Designing the Hi-DPI Web
ddemaree
275
33k
Transcript
Understanding XHProf Pinpointing 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 CTools https://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?