Author: Ivan Lisitsyn
We introduced WAPT Pro 4.0 about a month ago. It was a long awaited release that we had been working on for more than two years. The full list of new features is available here as usual. This looks more like a marketing message, of course. If you want to know what I personally think about each feature, I can provide different comments using the same list. This is a kind of exclusive information for the readers of this blog.
After several years of work with our customers I decided to summarize my experience by gathering the most common user confusions resulted in questions to our technical support service. I think that most of these issues were caused by wrong ideas or interpretations people may have had. In other words, in each specific case the problem was caused not by the lack of information, but rather by some sort of incorrect assumptions.
Of course, nothing like that would be possible if everyone spent couple hours reading the user guide before trying to use the product. But for some reason people rarely do it this way.
When you load test a web application and gradually increase the number of virtual users during the test, you usually expect to see gradually degrading performance parameters such as response time. The number of pages (sessions or hits) per second will reach maximum in some moment and will probably stay the same for the rest of the test despite the growing load. This is simply because the site cannot serve more requests per second, so it has to postpone the new coming ones.
In reality you will probably see something like that, but only for a limited time. When the load goes even higher, you can get another picture that may seem surprising at first glance. It is illustrated by the following three charts. Black line in all charts represents the number of virtual users.
Let’s suppose that you have already resolved all problems related to unexpected errors in your test. I mean that your site may produce some errors on heavy load, but the emulation of the user sessions is performed correctly and the error rate is acceptable. If this is not the case, or you have any doubts, you may want to read my earlier posts here and here.
If the errors are not an issue, your next step is to look at the most evident indicator of the application performance – its response time. This term initially refers to a time required for your application to respond to a user action. This looks very simple, but you should keep in mind the following things, if you want to analyze the test results correctly.