Traditionally, load testing tools create load in the protocol level. They emulated the traffic and not a full browser.
This fact has several good reasons:
- Conceptually – Load testing measures the response of the servers to load. It doesn’t matter what the client does.
- Scale – Executing in protocol level is far more efficient. It creates the maximum load on servers by generating the requests only, without the extremely high overhead of running thousands of browsers.
- Stability – In many cases, the protocol level is much more stable than the application. While the UI is changing according to usability needs, the server API’s are typically much more stable.
- Architecture – While in the older architecture, full pages were retrieved and much of the application logic was processed in the server, modern web application architecture are based on a thick client applications, either mobile or JavaScript and these application make API calls to the servers.
The above reasons are important, but they have a few drawbacks:
- The protocol/API level is tough to understand, and usually requires technical skills and familiarity with the application implementation details that some team members might not have.
- It is difficult to emulate exactly the same requests that a real browser would create in real time. Emulating the protocol level may be very similar, but not 100% identical. Only running a real browser gives the confidence that traffic to the application is emulated exactly like it would be created by real users.
- Existing automation/functional tests already created for functional requirements. Building different script for performance test requires extra time and expertise.
Adding browser load into the equation
The assumption that load testing doesn’t require paying attention to the client’s side isn’t completely right. It is correct that the server is tested and not the client’s application, but it important to remember that the target of performance testing is to create a good user experience with good performance. So, it’s a MUST to measure the client application performance under real load and test whether the goal is achieved. Measuring the protocol only is not enough.
This is why load testing tools integrate with tools like Selenium in order to add the real browser activity.
Adding real browser gives new capabilities:
- Measure the real user experience – As already explained above.
- Measure the real user experience from several locations by running browsers in several locations.
- Simulate different network situations and measure the user experience under different networks.
Browser load or Protocol load?
When testing load, it all depends on the number of users, and the measurements required. It can be browsers only, protocols only, or a mix of both.
For example:
- Max user’s capacity of 200 users – Can be tested via the protocol level with 1 Load Generator. As 200 users is not a big number, 200 browsers can be created easily with 5 load generators.
- Max user’s capacity is 1,000,000 – When testing a very big number of f users, it is not feasible to execute with real browsers. This must done on the protocol level, adding a few real browsers in order to measure the real user experience.
- Application’s APIs are being used by a 3rd party application – API’s are tested via the protocol level and verified that they hold the agreed number of requests.
When it comes to choose load, the true answer is a Hybrid.
We described the motivation and the pros/cons of protocol level load vs the browser level load. According to these guidelines, and your requirements you should pick the solution that suits you.
Let us show you how WebLOAD easily integrates with Selenium to create the best combinations of protocol level load and browser level load. Schedule a DEMO with us.
To learn more about load testing tools, read our updated blog on the Best Load Testing Tools of 2024.
