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.
Author: Ivan Lisitsyn
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.
As you probably know, the percent of secure HTTPS web sites is growing every day. Moreover, even if you do not care about security, the latest news from Google suggests that you will have to move to HTTPS in any case, because otherwise you will see your site dropping down in search results.
Depending on the implementation of your site, switching it to secure connection may take from few minutes to few weeks. You may face functional problems, broken links and thigs like that. Imagine that after you have done everything required, you finally see your site working under the perfect green line of the browser address bar. The question is: what have happened with the site performance, and should you load test it again?
Last week we released updates to our products, so it’s time to make some notes on this in addition to the official information, which (as usual) can be found on our site. In fact, I recommend taking a look at the list of new features before reading further. I would not say that we introduced anything to change the world of load testing, but few of the additions put us ahead of our competitors, which is definitely good. Let’s get to the list…