Enterprises must re-evaluate their approach to website performance management

In an RIA, the time to complete a Web page download may no longer correspond to something a user perceives as important, because (for example) the client engine may be prefetching some of the downloaded content for future use. 

Standard tools that measure the time for Web page downloads to complete can record misleading data for RIAs. In some cases, the client engine may not even invoke any standard Web page downloads once the application is launched, using asynchronous background communications for all server requests.

To implement RIAs successfully, enterprises must re-evaluate their approach to website performance  management. Instead of relying on the definition of physical Web pages to drive the subdivision of application response times, RIA developers or tool users must break the application into logical pages.

Read More on this topic.

Improving Website Responsiveness Involves Tradeoffs

It is easy for a measurement tool to sit on a server and measure all requests for service—and this kind of measurement has its uses, especially when load testing or investigating bottlenecks. But because of the variety of implementation possibilities, a common problem when measuring RIAs is that related requests may appear to originate from separate units of work on the client.

Correlating seemingly separate measurements with a particular application activity, task, or phase is tricky. The more complex the client/server relationship, especially when it involves concurrent interactions, the harder it becomes for measurement and analysis tools to perform that correlation properly.

Having more design and implementation options also creates new opportunities for developers to make performance-related mistakes. Accidentally or deliberately, developers can implement “chatty” client/server communication styles that perform extremely slowly under some workload conditions. Even with thorough testing, some of these problems may remain undiscovered until after the application is deployed unless applications are subjected to a systematic SLM process that includes measurement
activities to identify, investigate, and fix them.

Read More

To Understand And Measure An Application’s Performance

With RIAs, much of the execution of code in Web applications happens on the browser client, and not just the Web or application server, and therefore understanding what is actually happening inside a real browser has become imperative. To understand and measure an application’s performance, most Web monitoring tools try to emulate a user transaction using measurement technologies that use imitation, or emulated browsers.

These imitation browsers mimic, or emulate browsers like IE and Firefox to simulate a site or application visitor’s behavior. While emulated browser measurements have their place when simply monitoring for availability, a complete Web performance monitoring discipline must include both operational monitoring, primarily conducted using emulated browsers, and true end-user experience monitoring, conducted using real browsers.

Read More

Measuring Streaming Media Performance From The Customer Perspective

Along with the growth, however, have come significant challenges as streaming media points out to corporations and individuals the limits of their information infrastructure. These limits crash against the users’ demands for smooth video, clear audio, and performance levels specified and guaranteed by contract. Media providers seeking to provide consistent quality of service face a daunting array of web performance issues, caused by lack of last-mile broadband build-out to service interruptions and carrier quality of service problems.

One key to dealing with quality of service issues is accurately measuring streaming media website performance from the customer perspective. With the lack of industry standardization, customer confidence rests on providing information from a trusted source.

Unrealistic Load Testing Leads To Unrealistic Inferences

Website need to be tested under the most realistic conditions. These tests should be done using the arrival rates based on actual web logs and a real user – true to life scenario. This will help determine the revenue potential.

Earlier tests might have been conducted within your environment. But website performance testing would only be effective if conducted where the end users are. Unrealistic load testing leads to unrealistic inferences.  You will need true visibility into your end-user experience ensuring the success of your online business.

A big discrepancy in the page response times from different locations may point to the latency issues related to some backbones or the ten worst performing pages as the load level is increased indicating the pages causing performance bottlenecks.

Web Site Preparedness!

One of the major reasons why some companies don’t want to run a web load test on their production site is that they are not looking forward to performing activities such as the database back-ups and restores that a production site load test requires. We believe that such drills are a positive side-benefit of load testing. We have all heard stories of Web sites crashing under heavy load and taking many hours, or even days, to bring their system back.

Practicing system back-ups and recovery following a major load is an extremely important component of Web site preparedness. A load test on your production site will not only show you how well your system can handle a large load, but how well and how quickly your system and crew can recover from a site crash due to overload. If there are problems with post-crash recovery, the right time to discover and fix them is during a test, not while your site is experiencing real traffic peaks.

Read More