Microsoft Silverlight is a powerful tool for creating and delivering rich internet applications and media experiences on the Web. Its functionality is similar to Adobe Flash, integrating multimedia, graphics, animations and interactivity into a single runtime environment. Silverlight’s initial emphasis was on providing rich media experiences; enabling designers and developers to add rich degrees of interactivity, media and animation to their websites. Later versions extended its capabilities with many new features essential for business application development. As a result there has been an increase in business applications using Silverlight.
The world has changed dramatically for organizations that use web-enabled business applications in enterprise environments. The complexities of modern applications, which include multi-tiered, globally distributed architectures, SOA and a host of other new technologies, have forced major change in the way enterprises develop, test and manage web-enabled applications. Rich Internet Application (RIA) technologies such as Silverlight allow for a faster, more engaging, interactive experience with browser- enabled applications and services. While an attractive option for developing expanded application capabilities, these RIA technologies bring new challenges to organizations that need to deploy application features and functions in a compressed timeframe and at a lower cost.
In preparation, companies must adapt their testing approach. Given the way new technologies work when deployed on internet/intranet applications, it’s important to be careful in approaching the testing of Silverlight applications. When rolling out next-generation applications on a mission-critical enterprise application platform, you need to be confident your systems will perform. As load testing is one of the last crucial tasks before launching a web application, it’s usually done under pressure and with tight time constraints. Before we discuss tips to make you successful when load testing Silverlight applications, first let’s look at how Silverlight applications are unique.
Silverlight applications may be different from applications you’ve worked with before. For classic HTML web applications, the server does all of the processing. Additionally, the rendering of HTML requires full-page refreshes. Silverlight applications are different because content is delivered without having to reload the page. The server constantly updates the application asynchronously. For this reason, IIS server loads reveal a very different profile.
All testers know the importance of measuring transaction response times when performance testing web applications. But Silverlight technology can cause significant increases in the number of browser-to-server HTTP calls made in the background. This increase in traffic can have a profound effect on performance. While users might not be aware of the round-trips between the browser and a distant server, they will certainly be aware of performance problems if the application is slow or throws an error due to the increased load. Knowing the scalability limitations of your deployments is crucial.
Innovative RIA technologies like Silverlight present new challenges when attempting to emulate a realistic load. If you’re developing or deploying applications in this newer technology, successfully addressing these challenges requires thinking about load testing in new ways.
Let’s look at the new challenges in load testing Silverlight applications and three tips to improve application performance and enrich the user experience.
Tip 1: Make sure you can support Silverlight communication protocols
Silverlight applications can use multiple protocols to communicate with the server. Based on WCF (Windows Communication Foundation), the most common protocols are REST and SOAP with classic XML or binary XML. In order to accurately simulate users, your load testing tool must be able to support the various protocols used by Silverlight so that you can parameterize the requests, extract data from the response and validate the response. Without this capability, your tool will be unable to provide a realistic test design for your virtual users, rendering the results of the test virtually worthless.
The REST protocol
REST defines a set of architectural principles by which you can design Web services that follow some design rules. These rules imply the use of various HTTP verbs like GET, POST, PUT and DELETE. It means your load testing tool must handle all of these verbs to fully support RESTful web services. If not, some requests won't be played back, preventing the virtual user to run successfully.
The SOAP protocol
SOAP is a simple XML-based protocol to let applications exchange information over HTTP. There are two approaches testers can take to handle applications using this protocol. The first approach is to use an XML manipulation and the second is to use a load testing tool with a dedicated SOAP support capability.
A tool with dedicated SOAP support offers the following benefits over simple XML manipulation:
- It handles advanced features like WS-Security or attachments
- It is able to design performance test cases without the need to record the traffic from an existing client. Designing a SOAP request from scratch is very complex without the help of a tool. Yet when you automatically generate the request from a WSDL that contains the formal description of the web services, it improves productivity and ensures the requests are well formed.
Classic XML
XML is a text based format for encoding documents in a machine-readable form. Basic XML documents are easy to handle using regular string manipulations, yet extracting data or validating data from complex documents can be a challenge. XPath is a language used to navigate through elements and attributes in an XML document. It can be used to precisely locate appropriate data within the document. A tool allowing the use of XPath ensures that you can handle any XML document, no matter how complex.
Binary XML
Binary XML (MC-NBFX) and sub protocols like binary SOAP (MC-NBFS ) encode and decode XML documents in a binary format to decrease processing time and network bandwidth.
Many load testing tools rely on data being sent over HTTP and don’t tap into binary protocols.
Therefore, they don’t go deep enough to understand what is being exchanged between client and server. Make sure your load testing tool decodes the binary XML because it’s a requirement to be able to parameterize the request, extract data from the response and validate the response.
Tip 2: Automatically process application identifiers
Silverlight applications use identifiers for internal processing. Some are application specific and others are common to all Silverlight applications. These identifiers are used as parameters of requests and respond and work together. For example, an identifier returned by the server for one request is sent as a parameter for a subsequent request.
These identifiers change for each new communication between the client and the server. Playing back a recorded session as-is will cause errors due to the wrong values of the identifiers. You must extract and re-inject the appropriate values of these parameters at runtime. As the identifiers can be used in many requests, handling them manually may represent a large amount of work.
To avoid painful manual configuration of these parameters, make sure your load testing tool automatically detects and processes identifiers related to all Silverlight applications, and provides the ability to declare custom correlation rules that automatically process the custom identifiers.
Tip 3: Monitor the server side
If your test is running and the application has poor response times or throws errors, what is the root cause? Monitoring your servers during load testing helps find these issues in your server infrastructure.
Here is an example of typical performance counters that should be monitored for each component of a typical Microsoft application:
- Windows: Processor\% Processor Time, Memory\Available MBytes, System\Processor Queue Length, PhysicalDisk\% Idle Time, Network Interface\Output Queue Length…
- IIS: HTTP Service Request Queues\RejectionRate, Web Service Cache\File Cache Hits %, HTTP Service Url Groups\CurrentConnections…
- ASP.Net: ASP.NET\Requests Queued, ASP.NET\Requests Rejected, .NET CLR Exceptions\#Exceps Thrown / sec, .NET CLR Data\ SqlClient: Current # pooled connections…
- SQLServer: General Statistics\Logins/sec, SQL Statistics\ SQL Compilations/sec, Locks\Number of Deadlocks/sec…
What counters are required and what values are bad? Unless you’re a system expert, you need a tool that automatically selects the appropriate counters and sets alerts based on preset threshold values. Ideally, the tool should not only be able to set counters and threshold values from industry standards but should also enable customization of the settings based upon your specific requirements.
Results correlation is important for effective results analysis. With this functionality you can determine the cause of performance problems by correlating the response times and errors of the application with the performance counter of the underlying infrastructure. For example, if you see an alert related to a pool that reaches 100% of its capacity at the same time the response times increase abruptly, you've found the cause of the response time issue: the pool size has not been changed from its default settings and the size limit should be increased. Using the same tool to analyze the monitoring data you used to generate the performance test ensures you quickly find related events, greatly improving your productivity when searching for the root causes of performance problems.
As more companies deploy mission critical applications on the internet, performance testing these web applications under different loads before they go live has become increasingly important. While Silverlight provides expanded capabilities to develop new powerful applications in support of organizational needs, the technology is different from other applications. As a result, a new approach to load testing is required. To understand how your applications will work in the Silverlight production environment and to optimize them for higher performance, you need be able to simulate not just the actions of one user, but the actions of many users. By implementing the tips in this article, companies can quickly adapt their testing methodology to handle Silverlight applications, get to market faster and easier than ever before, while improving productivity and saving money.
About the Author
Rebecca Clinard is a Senior Performance Engineer at Neotys, a provider of load testing software for Web applications. Previously, Clinard worked as a web application performance engineer for Bowstreet, Fidelity Investments, Bottomline Technologies and Timberland companies. Her experience spans retail, financial services, insurance and manufacturing industries. Clinard’s expertise lies in creating realistic load tests based on metrics, recreating production performance scenarios and performance tuning multi-tier deployments.
She has been orchestrating and conducting performance tests since 2001. Clinard graduated from University of New Hampshire with a BS and also holds a UNIX Certificate from Worcester Polytechnic Institute.