Of the topics covered, WAN emulation is clearly closest to my heart, but please be sure to read up on Microsoft Vista support, the new RDP agent, and what is happening with LoadRunner’s Analysis API.

To read the full story, click here.

Do you plan to move to LoadRunner 9.5 or Performance Center 9.5 in the near future?  Will the integration with Shunra’s WAN emulation motivate you to upgrade or accelerate your upgrade schedule?

Standard terrestrial connectivity is frequently linked via satellites to enable a global reach for solutions accessed by both civilian and military personnel. The high latency and the asynchronous characteristics inherent in these satellite  links dictate particular attention when modeling test scenarios to determine application performance. It can be challenging to model these complex networks. Having worked with a number of our Fed Government customers over the years I’ve seen quite a lot of techniques used, some successfully, others with poor or inaccurate results.

The example shown below depicts a scenario in which the user is in a Humvee in motion. Three link conditions are defined and as test traffic is generated it is directed through the different links sequentially. These differentiated paths represent the change in the quality of service experienced when an end user’s position in relation to the uplink shifts. Satellite communication to the data center is also recreated here and in this case takes the form of asynchronous communication.

It is critical to be able to combine the diverse methods of transport and quality of service experienced in a single test. Can you do that now? If so, I’d love to know what method you are using. Are you using Shunra’s platform or another? What obstacles, if any, are you running into?

First off, VE Desktop for HP Software 5.0 is a new product.  It is in no way related to LoadRunner MWE.  HP/Mercury customers last saw MWE in LoadRunner 8.1 (July 2005) and the feature was removed from the LoadRunner 9.x releases.

While MWE was indeed “Powered by Shunra,” it was done so through an OEM relationship.  MWE was sold and supported by HP/Mercury.  VE Desktop for HP Software 5.0 development was a collaboration between Shunra and HP.  The product is the result of both companies learning from our experiences, designing, and co-developing a new solution that would exactly meet the needs of our customers.  VE Desktop for HP Software 5.0 can do everything LoadRunner MWE could, and much more.  VE Desktop for HP Software 5.0 is sold and supported by Shunra.

The top three issues we chose to address were:

1) Accuracy: Since the MWE did not support bandwidth emulation or jitter, the results of its emulations often did not fully reflect the real-world performance of applications being testing.  To address this, VE Desktop for HP Software supports bandwidth emulation (symmetric and asymmetric), jitter, imported network characteristics from Shunra’s VE Network Catcher, and a host of other network impairments aimed at precisely emulating network links.

2) Reporting: With MWE, there was no network specific reporting.  If a test was run with multiple locations emulated, the LoadRunner results would still show transaction response time and other metrics averaged across the whole test.  In order to understand how applications fared at individual locations, scripts would have to be modified so the script and transaction names reflected the location they were being run at.  This was very challenging to implement and maintain.  In VE Desktop for HP Software 5.0, there are no script changes required for such reporting.  For users of VE Desktop for HP Software, HP Analysis added the ability to sort results by “Emulated Location.”  HP also added the automatic import of network statistics on a per Load Generator basis.  Now users can understand their application performance by location and merge that data with network statistics like bandwidth utilization, latency and packet loss.  Finally, users can understand if the network is impacting their application performance and if so, how.

3) Performance Center: LoadRunner MWE had no compliment in Performance Center.  VE Desktop for HP Software 5.0 supports both LoadRunner 9.5 and Performance Center 9.5.  Within Performance Center, dynamic host allocation is fully supported.

VE Desktop for HP Software 5.0 provides a lot of other benefits beyond the direct improvements over MWE.  Some of those include a robust API and protocol analysis capabilities, but those are topics for other blog posts.

I look forward to your comments on the explanations above and any feedback you have about our latest addition to the Shunra family of products.

The Stimulus package include about $6 Billion to be spent in broadband technology and infrastructure, so obviously there is growing interest on how to capitalize on the expansion of broadband services, today only widely available by DSL or Cable TV.  We can compare our limited efforts with South Korea, where the KCC , Korean Communications Commission, the equivalent of our FCC, is planning to provide 1 GB broadband connections from the broadband providers, this is 200 times the speed of the average US DSL connection, at an estimated cost of $24 Billion, by 2012.  The KCC estimates that this will generate 120,000 new jobs, mainly in industries that had emerged in Korea as a direct result of the advance infrastructure, like MMO and online gaming.  It is easy to imagine the impact of wide broadband, and the potential it has to bring back to the US those call centers which were relocated to Manila and Malaysia. New jobs could be offered to unemployed or retired Americans who are at home using fast connections with VoIP and fast data transfers.  Think of the possibilities in remote education, collaboration software, new media and other innovative fields.

Money well spent? You bet.

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.

I have been working with Shunra users for several years now and I wanted to share my experience to help others avoid common network modeling roadblocks and fast forward the learning curve for our new users.

1. To emulate a symmetric link (say T1) of a remote branch (say NY) you will need to set bandwidth to T1 only once (on one ‘NIC’) on the ‘Gateway Shape’ which is contacted to the NY site. For example, set bandwidth value to 1544 Kbps in ‘NIC 1’ of ‘Gateway Shape 1’ (do not set 1.544 Kbps on ‘NIC 1’ and 1.544 Kbps on ‘NIC 2’ of the same ‘Gateway Shape’ – this will double the T1 affect).
2. To emulate an asymmetric link (say downlink is T1 and uplink is 256 Kbps) on one ‘Gateway Shape’ you will have to use the ‘Uni – Directional’ links and a gateway shape with at least 3 NICs on it. For example, use a gateway shape with 3 NICs (say ‘Gateway Shape 1’) and set 1.544 Kbps on ‘NIC 2’ and 256 Kbps on ‘NIC 3’. Next step is to connect ‘Gateway Shape 1’ to the WAN (in our case the WAN will be represented by a ‘WAN Cloud’ Shape). Use one ‘Uni – Directional’ link that goes from the WAN into ‘NIC 2’ (downlink = T1) and another “Uni – Directional” link that goes from ‘NIC 3’ to the WAN (uplink = 256 Kbps).
3. Remember if you are using a Ping command to monitor network delay of a real production link – Ping provides RTT (Round Trip Time) which is the time it takes the Ping request to reach the destination host plus the time it takes the Ping reply to reach the source host. In VE Modeler you will need to set Latency per direction and therefore you will need to set the Latency to RTT / 2.
4. VE Modeler 5.30 allows setting network delay in microseconds. When attempting to emulate Fixed Latency greater than 1 ms (say 30ms) – make sure you set the value in the Cloud Shape to 30.00 millisecond and not 00.30 millisecond. The later (00.30) stands for 300 microseconds..
5. A valid emulation path cannot have more than one ‘Link’ connected to the same ‘NIC’. Paths that come and go through the same ‘NIC’ will not be impaired.

I hope this helps.

Sharon Levin