An Equation to Explain Application Response Time

By Sevcik and Wetzel on Wed, 04/23/08 - 9:34am.

Ever wonder why it takes so long to get an application reply over the WAN? Why do applications that work well
during test and acceptance become performance dogs when rolled out to the user population? What factors
govern response time and what can be done to improve them? We developed a simple equation that explains the
basics.
Poor application performance renders users unproductive--therefore, application performance measurement over a
WAN must capture the user's experience. The most useful measure of the user's experience is task response
time.
A task is each user interaction with the application during a session or process. Task time is measured from the
moment the user enters an application query, command, function, etc. requiring a server response, to the moment
the user receives the response and can proceed. Some call this "user wait time"-or in the case of the Web, "page
load time" (PLT). The aggregation of these individual task completion times defines application "responsiveness"
perceived by the user.
Here is our easy-to-understand equation that shows the major variables affecting the response time a user
experiences.

Copyright 2000-2008, NetForecast, Inc.

Where:
AppTurns are the application client-server software interactions (turn count) needed to generate a user-level
system response or task. Turns do not include two-way TCP interactions (e.g., ACKs). The user is not aware of
turns.
Bandwidth is the minimum bandwidth (in bits per second) across all network links between the user and the
application server. The slowest link is typically the user's access line to the network. Useable link bandwidth may
be reduced by traffic conflicts (congestion) and protocol inefficiency (e.g., small TCP window size).
Cc (Compute Client) is the total processing time (seconds) required by the client device.
Cs (Compute Server) is the total processing time (seconds) required by the server(s).
Payload is information content (in bytes) that must be delivered to/from the user's device.
R is the task response time, which is the elapsed time (in seconds) between a user action (e.g., mouse click, enter,
return) and the system response (client, network, server), so the user can proceed with the process.
RTT is the round-trip-time (in seconds) between the user and the application server.
The AppTurn-RTT product is the key response time factor and it is growing at an alarming rate. Today's typical
business-to-business web page requires more than 90 AppTurns to load compared to just 50 AppTurns 5 years
ago. Furthermore, due to globalization and data center consolidation those pages are being delivered to users who
are farther away from the server. Multiply ever larger AppTurn and RTT values and you get a big number, which
causes a long response time.
The other culprit in the equation is payload size, which is also growing. Those same business-to-business web
pages average more than 500,000 Bytes in size, up from 150,000 Bytes 5 years ago. Yes, broadband helps but it
can't keep up if there is a lot of competing traffic causing congestion.
We used to recommend fixing the application, but that is no longer an option for most enterprises. The real
solution comes from the large array of application delivery system vendors. More on them later.

An Application Response Time Equation for Geeks

By Sevcik and Wetzel on Mon, 04/28/08 - 8:27am.

Last week we posted a simple equation to explain the basic factors influencing application response time. Because
it is pared down to show only the most influential factors and not all the factors affecting performance, our simple
equation uses an approximation sign. For those of you itching to dive into the bowels of application performance,
today we present a much more detailed equation that uses the equal sign. If you really want to understand why
your application response times are what they are, read on.
Here's the application response time equation for the number lovers among our readers.

Terms:
B Bandwidth (bits per sec)
Cc Client application render time (sec)
Cs Server application compute time (sec)
D Round trip delay (RTT) (sec)
K TCP Timeout (sec)
L Packet loss (fraction)
M Multiplexing factor
OHD Overhead (fraction)
P Payload (Bytes)
R Task Response Time (sec)
T Application Turns (count)
TPc Client turn processing time (sec)
TPs Server turn processing time (sec)
W Effective window size (Bytes)
The equation is made up of three major parts.
Part 1 - Discovery (Accounting for Turns)
The first line of the equation constitutes what we call the discovery phase. The discovery phase accounts for the
delay incurred as the client and server set up the payload transfer, and the value is driven primarily by the number
of application turns. Since these application turns typically use very small packets, their network performance is
limited by round trip delay.
The sum of each delay component (RTT plus protocol processing at the client and server) is applied as follows.
There is one initial turn that must be performed to get anything started. Then the remaining turns (T-1) are divided
by the multiplexing factor (concurrency) and finally a natural logarithm (ln) of the same value plus 1 is added. The
ln term is a phenomenon Peter Sevcik discovered many years ago when analyzing measurement data. We have
no fully cooked hypothesis for why it works, we simply know that it is required to get an accurate correlation of the
equation results to measurement values.

The final equation segment in the first line accounts for the impact of losing packets in the discovery phase. TCP
will wait for an ACK and if it does not arrive within the retransmission time-out period, it will resend the packet. This
adds yet more turns to the process.
Part 2 - Transfer (Moving the Payload)
The second line covers the transfer phase, and calculates how long it takes to transfer the payload. Payload
transfer time is limited either by the connection speed, or by the combination of window size and round-trip delay,
whichever is greater. This part of the equation calculates both times, and then chooses the larger value.
Note that overhead is added to the payload. Overhead is a percentage that accounts for HTTP, TCP and layer 2
bytes that are added to the actual payload to move it through the network. If 10 percent more bytes are required to
move the payload, OHD would be set to 0.1, which is the current situation on the Web.
Window size and round-trip delay affect the payload transfer because the server is only allowed to send a window's
worth of data before receiving an acknowledgement from the client that the data was received. The
acknowledgement time is limited by the round-trip delay of the connection. This parameter must be set for the
effective window that an application can realistically use. It is often not the full TCP window size since many web
page elements are small.
One more factor comes in to play: packet loss. The loss of each packet causes inefficiency in the TCP interaction,
which in turn slows the transfer. The denominator of the equation models this slowdown.
Part 3 - Compute Time (Application Processing)
The compute time phase in the third line accounts for how long it takes the server to run the application to produce
the result the user requested and for the client (typically browser) to render the result and display it on the screen.
In the days of client-server computing client processing used to be significant - remember "thick" clients? - then it
dropped a lot with the advent of browsers. It is now climbing again as the client must execute Java scripts.
How to Use the Equation
We suggest you experiment with the parameters for your specific application scenarios. This type of analysis can
help you predict a performance problem and find the parameters that, if changed, will provide the best
performance. We predict you will be shocked to learn how adding bandwidth or faster servers usually has little or
no effect.
If, after digesting this equation, you want to dive even deeper into the mathematics of performance, we recommend
you read our report "Understanding Web Performance" NFR5055, October 2001. The report also has a handy
companion Excel spreadsheet that will get you started on your analysis journey. Both are available on the
NetForecast web site under reports. (Be sure to scroll down to our 2001 reports to find them).

Hi,
I'm wondering if you put together the equation in attempt to solve an objective problem - what is my expected application
performance or response time, or if you're attempting to make your readers think that you're an uber mad-scientist oracle-type in
effort to sell services or products.
If it's the first, I applaud you. If it's the second, shame on you :) In either case, there are several other factors that should very
well be considered even though they probably fall into the realm of "other" as you describe above. I would challenge that the
"other" can easily outweight the items you list here:
- memory allocated to connection buffers on both read and write directions for the application
- number of connections being managed by the two TCP endpoints, and impact of context switching, paging, and other factors
related to this precious shared resource
- probability of packet loss beyond network packet loss and into buffer exhaustion on the recipient read buffer or sender transmit
buffer for both directions
- linearity/non-linearity of I/O impact imposed by each distinct operation being performed. Many applications can have this value
quantified to a ratio averaged over a series of commonly-sequenced operations

- congestion caused on either endpoint due to other applications running on either endpoint generating or receiving traffic, e.g.
what happens if I'm listening to streaming media at the same time
I think you and everyone else would agree that application performance can NOT be simplified into an equation accurately
because the vast majority of variables cannot be accounted for in a deterministic manner. The bigger problem is that even
attempting to chart such things leads one to question the validity of the findings because no one runs enterprise applications in
a vacuum, and the environment is dynamic and changes at a rate that is infinitely greater than the rate that anyone could
continue to update an equation.
So what are you trying to prove?