Application Performance Engineering Blog - Shunra Software » Network Test

Analyzing and remediating latency sensitive applications part 1

Amichai Lesser — Thu, 20 Aug 2009 20:04:17 +0000

Examples of latency sensitive applications

In the previous post http://www.shunra.com/shunrablog/index.php/2009/08/14/data-center-relocation-questions-and-answers-part-1/ I shared some of the questions that clients typically ask me during the performance analysis service in a data center relocation project. One of the most popular question, especially at the beginning of the project is “which applications are the most sensitive to network latency?”. Initially I thought of writing a post that categorizes and summarizes those applications, however, after reviewing the (long) list and reading through the analysis, I figured the community could benefit from some of the specific examples. I promise to try and summarize it all at the end.

MS Access on a shared drive – it’s only a good idea if your users like to wait

The first example is MS Access, and specifically, MS Access that is hosted on a shared drive. It takes very little latency (even 2.5 msec) to “break” the performance of an MS Access application deployed in such a way. The following example is one of many MS Access deployments that I had the privilege of testing, the results always look the same. The names of the transactions have been removed to protect the IP of the clients.

The baseline response time of a report generation transaction was 19 seconds. Once tested with 2.5 msec of latency, the response time jumped to 45 seconds, the following analysis reveals why:

Generate MS Access reports – 0 msec latency run

Without latency, this transaction spends about 10 seconds accessing the mdb file on the shared drive and the rest of the time is spent on executing the query to generate the report.

Generate MS Access reports – 2.5 msec latency run

Once network latency is introduced, this transaction spends 24 seconds accessing the mdb file on the shared drive and the rest of the time is spent on executing the query to generate the report.

So it is clear that there is a big performance penalty for file access, as by default file access is done using CIFS which is a protocol that is known to be very latency sensitive.

The following chart shows over 2300 CIFS File requests and over 1100 CIFS directory requests just for that single transaction.

So what can be done to improve the performance of this application?

There are several options when it comes to mdb MS Access files. In this example, the mdb file contained both the code and the tables. The first remediation attempt should be to export the tables to a SQL data base and link the SQL tables to the MS Access forms, this should reduce the size of the mdb file and thus reduce the performance penalty associated with accessing the MS Access mdb file remotely.

A more beneficial approach but at the same time, one that requires more changes, would be to export the tables to a SQL data base and replace the MS Access forms with web based forms. This architecture will eliminate the file server access completely as the client would be accessing data via a browser.

How was the analysis performed?

The above test used VE Network Appliance, VE Analyzer, VE ClearSight, VE Transaction Manager and Wireshark. The baseline and latency tests were conducted by isolating a client workstation behind the network emulator and injecting 0 and 2.5 msec of latency. During the test we used the packet list within the VE Modeler to capture the transaction traffic and we timed the response time using VE Transaction Manager.

At the end of the test we used VE Analyzer to perform deep packet analysis. Part of the analysis reports include the transaction markers report which enabled us to isolate the 2 transaction runs in WireShark (baseline and latency). The last step was to generate the above IO graphs in WireShark. These charts demonstrate the difference in the timeline and transaction footprint between the baseline run and the latency run. VE ClearSight was used to analyze the SMB protocol (CIFS) and to generate the last chart.

Washington Mandates Health Data Revolution

Jeffrey Churchill — Tue, 21 Apr 2009 20:22:20 +0000

The recent passage of funding to address ineffienciacies in patient record creation and information transfer has created a new opportunity for pre deployment application testing.

Current “paper based” systems are impracticle and expensive to maintain. Due to the enormous amount of digital data that will replace current files a systemic test methodology must be instituted to “right size” storage and network solutions supporting this endeavor.

An example of potential savings is an engagement with a company providing Oncology Radiological treatment and patient scanning. They package both the software and MRI hardware to regional clinics offering this service. Historical application performance has dictated a locally hosted server environment to house the images and patient information. There has been no WAN testing to determine whether a regional data center option is viable. The added cost of these local servers and HVAC and power add millions to the cost of the overall solution.

These are hard dollar savings that can be realized with no sacrifice to the speed or accuracy of the results. All that is required to architect a more efficient storage infrastructure is to institute network designs tested under WAN conditions representing the regional support network.

A simple solution to a complex challenge.

What’s new in LoadRunner 9.5 – the rest of the story

Dave Berg — Wed, 25 Mar 2009 20:29:32 +0000

One of my favorite partners to work with is LoadTester. Not only are they competent and efficient, but they are nice and will tell you what they really think. Their latest update on HP’s latest release of LoadRunner 9.5 goes into a lot more detail than any readme file will, with perspective and colorful commentary around each of the improvements that might be important to you.

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?

VE Desktop for HP Software 5.0 versus LoadRunner MWE

Dave Berg — Fri, 06 Mar 2009 17:06:30 +0000

Earlier this week, Shunra announced the release of a new product, VE Desktop for HP Software 5.0. This product is embedded into HP’s LoadRunner 9.5 and Performance Center 9.5 products and from the surface, looks a lot like a previous feature in LoadRunner called Mercury WAN Emulation (MWE). Because of the obvious similarities, there have been a number of questions about the differences and any upgrade rights for legacy MWE customers. This blog will hopefully dispel any uncertainty and give you a clear understanding of how everything works.

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.