Gone are those times of static websites and thanks to AJAX and other new concepts the interaction with web-based services are very natural nowadays. Content gets updated dynamically, and there is no longer a need to wait for an updating web page. In this post, I will give you some background on the technology behind, followed by pros and cons and a recommended load and performance testing strategy.
At the beginning of our Internet age, the popularity of content-rich and interactive web pages was terrible because there was no option to update a web page without a reload of the whole page. AJAX has closed this gap and introduced asynchronous data load concept, which enables a user to interact with the page while data loads in the background. An AJAX request consists of the following steps
1. User clicks through the web page
2. The handler of this web page creates an XMLHttpRequest object
3. XMLHttpRequest object requests a document from the server
4. The Server retrieves appropriate data and sends it back
5. XMLHttpRequest fires an event to notify the web page the data has arrived
6. The handler processes the data and displays it
What challenges come with AJAX applications?
Apparently, there are pitfalls involved in that dynamic AJAX based web pages, which are already well known in the developer community. Let me summarize the problem spots in this AJAX area below.
Secondly, dynamic 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 vast extent of content is not visible to those indexing engines.
Thirdly, the ongoing dynamic page updates can disturb the user of your sites because the attention span is not too high and the more active elements pop up on those pages, the higher is the chance that your user gets interrupted and cant 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 or headless 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 testing script creation, it’s 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 communications 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
Sample protocol and browser based load testing scripts
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. User types, search terms matching content will be displayed. After a user hits the search button, the corresponding search results will be loaded step by step through the AJAX concept.
The waterfall chart below was created with Chrome. The response time of my “car” search request was 2.2 seconds.
I used the developer tools of Chrome, which helped me to figure out that it executes 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: Post https://ajaxsearchpro.com/?s=car
Simulation approach: Protocol level, Chrome
Response Time: 594 ms
Number of requests: 1
Summary of this protocol based script execution
Browser-based AJAX load test script
Scripted steps: https://ajaxsearchpro.com/?s=car
Simulation approach: Full Browser, Chrome
Response Time: 2.18 sec
Number of requests: 32
Summary of this browser-based script execution
Comparison of both simulation methods
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 will miss 10000 x 31 = 310000 requests. Naturally, this would lead to entirely inaccurate load test results.
Due to its asynchrony communication pattern, AJAX based applications can’t be automated on the protocol level. Only browser-based user simulation provides accurate load testing results and generates a realistic load on your backend system.