A recent study of our clients has revealed an interesting phenomenon: the number of universities, school districts, training centers and all other types of commercial and non-profit educational organizations is disproportionally high among the users of our load testing tools.
We released the latest versions of our load testing tools few months ago. All users who have had an opportunity to update their product installations already know that two major features in that release were the support of HTTP/2 protocol and the ability to execute concurrent requests in each user session. In fact, each of those features is a complement to the other one, because the development of HTTP/2 was inspired by the idea of concurrency in the first place.
Yet, it is true that not every web application has switched to the new version of the protocol by now. So, what if your test project does not require any of these major features? Will you get any benefits after upgrading to WAPT Pro 5.0 from the previous version of the tool?
We have been working on this for quite some time. Now a new version of WAPT Pro is about to appear, and this time we decided to start with releasing it in beta. Even though the tool GUI looks almost unchanged, all parts that actually do the work (test recorder and load generation unit) have been completely rewritten. This was not done just to squeeze out a few percent of performance or because the old code was bad. It was very good for executing user sessions consisting of successive HTTP requests. This concept is still applied by the majority of the load testing tools, but we wanted to become the true concurrency pioneers.
When I speak to our CEO, who is in charge of our marketing processes, he keeps telling me that there are too many vendors like us in the IT world and we desperately need to differentiate somehow to be spotted by anyone out there.
The “try before you buy” concept does not work anymore. Trying something is an exhaustive task. People cannot oblige themselves to toil that much. Worst of all, even after you’ve tried a lot, you may still be uncertain if that was a good experience or not.
When you plan a load test, one of the first things you need to know about the backend configuration is if it includes a load balancer. This is important because most load balancers distribute new user sessions by the client IP address. Some of them allow changing the distribution method. However this may be achievable only by a significant configuration change. You will hardly persuade the site admins to make such changes in the production environment.
What is a bit embarrassing in this respect is that even if you select the “distribute to the least loaded” option in LB settings, this may still mean that it will use this rule only for new IPs. After the initial connect, each IP is remembered for a certain time (from 1 hour to few days) and all new connections from the same IP will be directed to the same web server.
This creates a very big problem for load testing. If you use WAPT Pro, or any other efficient load testing tool, by default all your virtual users will share the same IP address and will be directed to the same web server behind the LB. As a result, you will not be able to test the whole system correctly.
