In the previous post I presented an approach for making sure that the network models used in a test are up to date. I also mentioned that in cases where the enterprise network is very dynamic, a more rigorous approach is needed. It is important in these cases to test applications for a range of network conditions per link, specifically for best case, average case and worst case profiles for each link. In this post I want to describe this best practice and offer some tips in implementing it.
On the surface, answering the question “How will this application perform from a remote site?” seems pretty straightforward. One needs to emulate the network conditions of the link from the remote site to the data center and then test the application under those emulated network conditions. However, in practice answering this question is often more challenging. Specifically, enterprise networks are very dynamic with conditions that change based on the time of day and day of the month. This increases the challenge of selecting which network conditions to use in each test. A test that doesn’t reflect the entire gamut of network conditions may miss potential problems, on one extreme, or lead to teams over reacting to bad results on the other extreme.
This means that there isn’t a single response time metric that can tell us how an application will perform in a remote site. This is where the remote site performance range comes into play. The performance range predicts application response times under best, average and worst case network scenarios for each remote site. By testing for a range of network conditions the tester can confidently make a statement such as “when the network is idle (best case network condition), a user from this remote site will experience a 7 seconds response time, on average the response time will be 10 seconds and during worst case network scenarios the response time will increase to 17 seconds.” (These response times are used for illustration purposes only and aren’t offered as guidelines).
A report that summarizes the test results of a performance range may look like the following, where each transaction from each site is presented with its measured performance range:
|
Site |
Transaction |
Best Case [Sec] |
Average Case [Sec] |
Worst Case [Sec] |
|
NY |
Sign in |
5.30 |
7.20 |
10.30 |
|
View Spending report |
6.20 |
7.30 |
8.40 |
|
|
View Credit Report |
10.10 |
15.20 |
23.50 |
|
|
Submit changes |
3.30 |
4.50 |
5.50 |
|
|
Sign out |
1.10 |
1.20 |
1.50 |
|
|
Boston |
Sign in |
5.83 |
7.92 |
11.33 |
|
View Spending report |
6.82 |
8.03 |
9.24 |
|
|
View Credit Report |
11.11 |
16.72 |
25.85 |
|
|
Submit changes |
3.63 |
4.95 |
6.05 |
|
|
Sign out |
1.21 |
1.32 |
1.65 |
|
|
Chicago |
Sign in |
7.00 |
9.50 |
13.60 |
|
View Spending report |
8.18 |
9.64 |
11.09 |
|
|
View Credit Report |
13.33 |
20.06 |
31.02 |
|
|
Submit changes |
4.36 |
5.94 |
7.26 |
|
|
Sign out |
1.45 |
1.58 |
1.98 |
|
|
San Francisco |
Sign in |
8.40 |
11.40 |
16.32 |
|
View Spending report |
9.82 |
11.56 |
13.31 |
|
|
View Credit Report |
16.00 |
24.08 |
37.22 |
|
|
Submit changes |
5.23 |
7.13 |
8.71 |
|
|
Sign out |
1.74 |
1.90 |
2.38 |
|
|
Seattle |
Sign in |
10.07 |
13.69 |
19.58 |
|
View Spending report |
11.78 |
13.88 |
15.97 |
|
|
View Credit Report |
19.20 |
28.89 |
44.67 |
|
|
Submit changes |
6.27 |
8.55 |
10.45 |
|
|
Sign out |
2.09 |
2.28 |
2.85 |
|
|
London |
Sign in |
12.09 |
16.42 |
23.49 |
|
View Spending report |
14.14 |
16.65 |
19.16 |
|
|
View Credit Report |
23.04 |
34.67 |
53.60 |
|
|
Submit changes |
7.53 |
10.26 |
12.55 |
|
|
Sign out |
2.51 |
2.74 |
3.42 |
|
|
Tokyo |
Sign in |
14.51 |
19.71 |
28.19 |
|
View Spending report |
16.97 |
19.98 |
22.99 |
|
|
View Credit Report |
27.65 |
41.60 |
64.32 |
|
|
Submit changes |
9.03 |
12.32 |
15.05 |
|
|
Sign out |
3.01 |
3.28 |
4.11 |
In a future post, I will go deeper into how to model a network link to represent a best case, worst case and average case scenario.

July 29th, 2009 at 8:47 pm
How will this application perform from a remote site? http://tinyurl.com/l86r9e
May 13th, 2010 at 10:07 pm
I found this on Yahoo and just wanted to thank you for the suggestions in your blog entry. I will take my time and browse other sections of your site and add it to my favorites.