An Application Response Time Equation for Geeks

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: Bandwidth (bits per sec) Client application render time (sec) Server application compute time (sec) Round trip delay (RTT) (sec) TCP Timeout (sec) Packet loss (fraction) Multiplexing factor Overhead (fraction) Payload (Bytes) Task Response Time (sec) Application Turns (count) Client turn processing time (sec) Server turn processing time (sec) 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 EquationWe 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).

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey: The results are in