Load Testing AJAX Applications
identify issues, and validate performance under load.
- AJAX LOAD TESTING IN ACTION
- HOW DOTCOM-MONITOR SOLUTION LOADVIEW ADDRESSES LOAD TESTING WITH AJAX
- TOOLS USED
What is AJAX?
Those of you who’ve had to deal with load testing of AJAX based applications have learned that this is often a nasty development and automation challenge. This page will provide some background on AJAX, followed by pros and cons and a recommended AJAX performance testing approach.
Fifteen years ago, web pages were boring but extremely lightweight, easy to maintain, and their testability was fantastic. Users often spent more time waiting in front of a white screen than interacting with those early web applications. Due to this limited usability businesses avoided spending money on new web-based services.
In the beginning of the Internet age the popularity of content rich and interactive web pages was bad because there was no option to update a web page without reloading the whole page. AJAX closed this gap and introduced the asynchronous data load concept, which enables an end-user to interact with the page while data loads in the background. Nowadays, this concept is widely used because it allows implementation of interactive web applications.
A typical AJAX requests consists of:
- User clicks through the web page
- The handler of this web page creates an XMLHttpRequest object
- XMLHttpRequest object requests a document from the server
- The Server retrieves appropriate data and sends it back
- XMLHttpRequest fires an event to notify the web page the data has arrived
- The handler processes the data and displays it
What challenges come with AJAX applications?
Obviously, there are pitfalls involved in dynamic AJAX based web pages, which are already well known in the developer community. Let us summarize the problem spots in this AJAX area below.
Secondly, dynamically loaded and displayed data is not part of the page. If a search engine has indexed your AJAX based web application the result can be unsatisfying because a great extent of content is not visible to those indexing engines.
Thirdly, the ongoing dynamic page updates can disturb users with a low attention span. The more dynamic elements pop up on those pages the higher is the chance that your user gets interrupted and can’t finish their work within acceptable time.
Finally, due to the callback-based client-server communication latency is several times higher compared with web sockets. Web clients poll for data updates which is also a challenge for automated testing.
User simulation techniques
Load testing specialists are responsible for choosing an appropriate user simulation approach, which is both, suitable for your application under test and generates not too much effort. If you choose the wrong simulation method the chance is very high that you can’t tackle performance hotspots in your application.
There are two user simulation methods.
1. Protocol based simulation of requests and responses
Most of the open source testing tools and also all commercial load-testing tools support this procedure. You record client-server interactions and the testing tool captures all requests and responses into a test script. After parameterization of dynamic data such as session IDs or test input data the scripts could be used to simulate the required load on your backend system. Be aware that client side processing or interactions are not part of your protocol level response time measurements.
2. Full browser based simulation of real user interactions
Only the outstanding players in the load testing business support this simulation approach. The reason for this is that the system resource requirements are higher and reliable replay is tricky to implement. When it comes to test script creation its similar to protocol-based approach. The tester navigates through the web page while a script recorder captures all interactions in the web browser. During test execution a headless web browser executes the recorded interactions and responds to server callbacks similar to a real user. This type of user simulate is very accurate and provides realistic frontend performance metrics.
The former simulation method is perfect for static web applications, has a low simulation overhead on your load injection machine and is often easy to implement. The later technique provides accurate end-to-end response times but their overhead on the load-testing server is much higher. So, how would you choose the best user simulation method for your next AJAX based load test?
AJAX load testing in action
What is the best AJAX load testing approach and how can you validate your decision? Obviously, it’s a good idea to start a small experiment if you are not sure what approach would provide accurate results.
I will give you now two sample load test implementations for an AJAX sample application https://ajaxsearchpro.com. This demo application is a simple search engine. During a user types search terms matching content will be displayed. After the enter key fired or the search button is clicked the final search will be executed and the corresponding search results will be displayed on the screen step by step.
This is the waterfall chart captured with my Chrome browser. Response time of my “car” search request was 2.2 seconds.
I used the developer tools of my Browser, which helped me to figure out that it executes the this request when performing the search action: https://ajaxsearchpro.com/?s=car
I’ve created a protocol based and a browser-based load test script, executed both and compared the resulted performance metrics. What do you think? Which user simulation is the best for an AJAX-based application?
Protocol based AJAX load test script
|Scripted steps:||https://ajaxsearchpro.com/?s=car||Response Time:||594 ms|
|Simulation approach:||Protocol level, Chrome||Number of requests:||1|
Browser based AJAX load test script
|Scripted steps:||https://ajaxsearchpro.com/?s=car||Response Time:||2.18 sec|
|Simulation approach:||Protocol level, Chrome||Number of requests:||32|
Comparison of both simulation methods
Due to its asynchrony communication pattern, AJAX based applications can’t be automated on protocol level. Only real Browser based simulation provides accurate results and generate a realistic load on your backend system.
Consider a load test of our AjaxSearchPro demo application with 100 concurrent user and 10000 searches per hour. If you decide to use the protocol-based simulation, you would miss 10000 x 31 = 310,000 requests. Obviously, this would lead to totally inaccurate load test results.
How Dotcom-Monitor’s LoadView Solution Addresses Load Testing with AJAX
Our cloud-based load-testing platform LoadView is designed for testing all modern web 2.0 applications such as AJAX, Flash, HTML5 or jQuery. Its ease of use is outstanding. You can record full browser-based scenarios and simulate more than 40 mobile or browser-based devices such as Internet Explorer, Chrome, iPhone, Samsung, Blackberry and many more.
Many load-testing solutions provide just a protocol-based user simulation approach, which is not enough. You can stress your backend with protocol level testing, but a significant part of client-server requests and client-side processing is left out. Our LoadView platform gives you everything that you need when it comes to accurate user simulation.
5 Steps to run your AJAX based load test with LoadView
1. Record your AJAX application
You can use our EveryStep Web Recorder to manually navigate through your AJAX based application. Everystep will record all actions and allow you to add timer or verification steps. Once you’ve clicked through your system under test you can perform a single user trial run or upload the recorded actions to our platform and create your load testing device.
Assignment of load injection machines is often guesswork. Unhealthy load generation machines will falsify your test results. LoadView executes a single user test run of your device and calculates the max number of users per load injection machine. This step avoids that an overloaded machine negatively impacts the response times of your application.
3. Execution Plan
User volume often varies along a typical business day. We addressed this need with our execution plan feature. It gives you full flexibility to model realistic load test scenarios.
4. Virtual user distribution
LoadView lets you choose between a broad range of load injection machines around the world. Select those, which represent the usual location of your customers.
5. Run the test and get your results
In this last step you can kick start the load test execution. An online view will give you real time insights about how your AJAX application performs under load. Once your test execution has finished you will receive a detailed report with the most important key performance indicators.
All things considered, LoadView fulfills all requirements of a modern load testing platforms, simplifies test automation challenges and helps you to simulate real production like scenarios on your complex business applications.
LoadView: Cloud based load-testing platform from Dotcom-Monitor
EveryStep Web Recorder: Scripting tool from Dotcom-Monitor
Chrome Developer Tools: Analysis of the communication pattern
To learn more about the Dotcom-Monitor platform, visit www.dotcom-monitor.com