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
Real User Monitoring Web App Performance
Web App DB
• How can I avoid being • Why is my application
blind-sided by slow?
performance issues? • Which tier is causing the
• Which users are being slowdown?
affected? • Is it inside or outside the
• How can I troubleshoot data center?
specific user issues? • How can I recreate or
validate problems?
12
Service Level Assurance
• What is the impact of
performance problems
on the business?
• How do I link
performance criteria to
specific business units?
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