1
Slow Cool, Ain’t Cool
Optimizing 'Web 2.0' Application Performance
Hon Wong, CEO, Symphoniq Corporation
Agenda
Ajax Web 2.0 apps…
new opportunities
new performance management challenges
Real user approach needed
New approach in action
Q&A
2
The Evolving Web
3
Web 2.0
Web as computing
platform
“Users add value”
3
All In The Name of the End User
4
“The Next Big
Killer App / Feature”
Rich Internet Ubiquitous Computing
Applications (RIA) and Access
Brittle Architectures Loosely Coupled Dynamic Architectures
Architectures
Rigid Taxonomies “Semantic Web”
Loose Folksonomies
Web as Information Web as Information
Source Web as Information Synthesis
Collaboration
Web 1.0 Web 2.0 And beyond…
4
Challenges of the Rich User
Experience
5
New New
Use Cases Technologies
Distributed, high volume Complicated Architectures:
publish/subscribe model SOA, Web Services, REST, XML
Organic, user driven application More chatty protocols / higher
evolution with no QA process frequency of connections
Reuse of existing internal or 3rd party More logic on the client, creating
services or content another potential bottleneck
Loose “folksonomies” replace rigid RIA containers reduce visibility into
“taxonomies” in data structures client experience
5
Dealing with the Challenge
6
Web App DB
Traditional tools & techniques generate External App
oceans of data – no solutions
• Log file analysis
• HTTP watch
• Network sniffers
• Load testers
• Server monitors
• Monitoring services
• Many more…
Reality Check
7
“43% of all application outages aren’t
detected by the tools put in place to
manage them, but by the end-users who
are subjected to them”
Dennis Drogseth, VP, Enterprise Management Associates
And Even if A Problem is
Discovered…
8
While most problems get solved in less than a day,
30% of problems take more than a day to solve.
18.00%
16.00%
14.00%
12.00%
10.00%
8.00%
6.00%
4.00%
2.00%
0.00%
<1 hour 1-2 2-4 5-10 10-24 1-2 days 2-5 days > Forrester
5 days Research
hours hours hours hours
Performance Management:
Practical Question #1
9
“Living is a form of not being sure, not
knowing what next or how…We guess. We
may be wrong, but we take leap after leap in
the dark.”
Agnes de Mille
When user satisfaction has direct business impact, do you have
the luxury of blindly assuming users are satisfied with
application performance?
Performance Management:
Practical Question #2
10
"I'm an ocean, because I'm really deep.
If you search deep enough you can find
rare exotic treasures.“
Christina Aguilera
When business happens in Web time, do you have time to
search oceans of performance data to pin-point the cause of
slowdowns?
Performance Management:
Practical Question #3
11
“Strive for continuous
improvement, instead of
perfection.”
Kim Collins
When complexity and high-speed change
make perfection unattainable, do you have the actionable
information required to drive performance improvements?
Holistic Approach to
Performance Management
12
Real User Monitoring Web App Performance Service Level Assurance
Web App DB
• How can I avoid being • Why is my application • What is the impact of
blind-sided by slow? performance problems
performance issues? • Which tier is causing the on the business?
• Which users are being slowdown? • How do I link
affected? • Is it inside or outside the performance criteria to
• How can I troubleshoot data center? specific business units?
specific user issues? • How can I recreate or
validate problems?
Bottom Line Impact of
“Do Nothing”
13
Time and resources consumed Distraction from core
Trying to isolate problem business
Wasted IT
Employee
Blame game budget
Reduced
downtime triage
productivity
Brand damage Slow = Off
Customer Lost revenue
abandonment
Inadequate tools
Blindsided by Incomplete
transactions
to detect and
diagnose
performance problems
issues Compromise
strategic
Wasted Resources initiatives
Costs 10x to fix the
problem in production
Why Monitor from the Real
User Perspective?
14
Calculating end user response time is not
practical…
RT ≈ (Payload / Bandwidth) + (AppTurns * RTT) + Cs + Cc
RT Response time of the transaction in seconds
The amount of information (bytes) that must be delivered to
Payload
the user
Minimal bandwidth across all network links between the user
Bandwidth
and the data center
Number of user and web site interactions needed to
AppTurns
generate a user-level system response to a transaction
Round-trip-time between the user and the data center
RTT
Total processing time required by the data center consisting
Cs
of web servers, application servers and database servers
Cc Total processing time required by the user’s PC
How Real-Time Apps Derail RT
Calculations
15
Parameter Limitations
Varies greatly transaction to transaction
Payload 3rd party or cached content
Non-page content like AJAX, Flash, Silverlight
Varies greatly from user to user
Bandwidth Varies from moment to moment
Varies greatly transaction to transaction
AppTurns 3rd party or cached content
Non-page content like AJAX, Flash
RTT Varies from moment to moment
Varies from transaction to transaction
Cs Dynamic data center—what “path” will the transaction take?
Difficult to instrument applications, esp. 3rd party code
Varies from user to user, moment to moment
Cc Impacted by “last mile” conditions
Measuring or Estimating Real User
Response Time (RT)
16
RT derived through
Measuring RT directly
measurement of
at the browser
surrogate parameters
Measuring RT by
“listening-in” and
not adding load Empirical / Approximate Direct
Installed Agent
Passive Sniffer or
Dynamic Injection
Active Synthetic Monitoring (not applicable)
Measuring RT of
artificially created
transactions
Direct Measurement at Browser –
Only Viable Approach for Ajax
Apps
17
Web applications do not “come together” until
the user’s browser
Last mile connectivity issues
– User side bandwidth or caching
– Chatty protocol (e.g., XML)
– Content delivery network
User side resource limitations impacts Web 2.0 features
– Javascript
– Media players (e.g., Flash, Silverlight)
Mash-up, SOA & SaaS mask performance issues
Computing in the Cloud beyond the datacenter
Measuring or Estimating Real
User Response Time (RT)
18
RT derived through
Measuring RT directly
measurement of
at the browser
Installed Agent
surrogate parameters Dynamic Agent
Measuring RT by
“listening-in”
• Download andmonitoring agent to PC
• Dynamically injects probe onto
not adding load Empirical browser via WebDirect
server or ADC
• Difficult & expensive to implement
– Convince users to download • Non-intrusiveInstalled Agent
Passive
– Maintain agents Sniffer – No agent download
or
– Potential compatibility issues Dynamic
– No source Injection
code changes
• Measure RT, errors & desktop • Measure RT & errors
statistics
Active Synthetic Monitoring • Applicable to
(not
all applicable)
customer-facing
• Only suitable for PCs under IT’s or enterprise applications
direct control Measuring RT of
artificially created
transactions
Beyond Monitoring – End-to-End
Management
19
HTML, AJAX, Flash,
Silverlight Web App DB
External App
Tier Time Detail
Web
App
SaaS
DB
Ext 1
Management
Server + DB
Ext 2
Total
Meaningful, Correlated &
Actionable Data
Everything 20
RT (as experienced by the end- measured from
user) the real user’s
Affected Party’s IP Address and URL perspective
Network Latency
Parsing Time
Objects Per Page
Object Response Time
Error or Abort Rate Correlated across all tiers of
Base Page Response Time network & infrastructure
Response Time at Web, Application &
Database Tier
Server Responsible at Each Tier
Server Parameters: CPU utilization, Memory,
I/O etc.
Web Service Calls
Method Call Tree Insight into application
SQL Queries
Real Time, End User Experience
Driven Problem Resolution
21
Detect Problem Based on RT
Assess Impact
Prioritize Issues
Outside Inside
Outside or Inside?
Client or Network? Front or Back End?
Client Network Front End Back End
Identify Identify Which Page, Which Object
Individual User Individual IP Object, Web and Server?
Service, Server?
Trace Call Stack
Method Call or
Solve The Problem
SQL Query?
Performance Measurement
Based on Real Users
22
Quick Triage
23
• Directly relate real user RT to IT issues
― Not impacted by infrastructure configuration
― Accommodate 3rd party content, SOA etc.
• Focus resources on fixing the problem instead of
reproducing the problem or pointing fingers
Tuning Web App.
Performance Using Real Data
24
Requirements Optimize
Design
Operate
Build Deploy
Development Phase Production Phase
Discover & fix performance bottle-necks
under load prior to rollout
Real-time detection & mitigation of
performance issues
Complexity Creates a
Spectrum of User Experiences
25
HTML
AJAX Web App DB
Flash,
Silverlight
# of Occurrence
External App
Response Time
How to Report App. Perf. to
Business Owners
26
One approach: Application Performance Index (Apdex)
Standardized method for reporting app. perf. as defined by an
alliance of companies and users (www.apdex.org)
Reduced myriad of perf. metrics into a 0-to-1 scale (0=no user
satisfied, 1=all users satisfied)
Num. Satisfied Users + ½ Num. Tolerating Users
APDEXT =
Total Num. Users
=4T
Aligning App Perf to Business
Goals
27
Sample Apdex Report
28
Requirements of a
Comprehensive Tool
29
Detect Isolate Optimize
Web App DB
• Provides visibility into • Isolate problems by • Report on business
browser-level tagging and tracing impact of performance
performance, including transactions through problems
RIAs internal and 3rd party • Optimize application
• Detect performance J2EE and .NET services performance with
problems in real time to • Visibility into problem historical trending and
minimize impact servers, services, analysis
method calls and SQL
queries
30
Thank you!
For more information:
Hon Wong
CEO
Symphoniq Corporation
(650) 213-8889 x101
hon@symphoniq.com
www.symphoniq.com
