WAPT usage

Testing of a website behind a load balancer
Testing practice WAPT usage

Testing of a website behind a load balancer

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.

Load testing of HTTPS web sites
Testing practice WAPT usage

Load testing of HTTPS web sites

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?

WAPT 9.3 and WAPT Pro 4.3
WAPT usage

WAPT 9.3 and WAPT Pro 4.3

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…

Response validation with JavaScript code
WAPT usage

Response validation with JavaScript code

One of the benefits of the Pro version of WAPT in comparison with the regular one is that you can insert JavaScript code inside profiles to handle various calculations. This can be used to parametrize complex user sessions when session-specific values are not contained in the response page code explicitly. Another example is when you cannot extract values from the response with help of standard functions, like “Search Parameter”, because bounding text may be variable. So, you need to implement more complex search algorithms to find the right value occurrence.

What I like the most in WAPT Pro 4.0
WAPT usage

What I like the most in WAPT Pro 4.0

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.

12 typical confusions for a novice load tester
General Testing practice WAPT usage

12 typical confusions for a novice load tester

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.

Performance glitches on charts
Testing practice WAPT usage

Performance glitches on charts

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.

How to analyze a load test report? Part 4: Response time.
Testing practice WAPT usage

How to analyze a load test report? Part 4: Response time.

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.

Connecting to WMI on a remote system
General WAPT usage

Connecting to WMI on a remote system

Windows Management Instrumentation (WMI) is one of the common interfaces used to retrieve information from a Windows system. Such information can include values provided not only by the system itself, but by various software programs running on it. That is why WMI is widely used to monitor the performance and correct operation of the server components.

Many load testing tools, such as WAPT Pro, can monitor performance counters directly from the tested servers with help of WMI. The most useful counters are those representing CPU, RAM and network usage, but there can be other server-specific ones that you can easily retrieve.

How to analyze a load test report? Part 3: Errors.
Testing practice WAPT usage

How to analyze a load test report? Part 3: Errors.

If you see any errors after executing a load test, first of all you should check if this is a test design problem. I wrote about the most typical problems of that kind here.

Now let’s suppose that the test was designed correctly and any errors we see in the report are related to the load you created in the test. In other words, I would like to talk about errors that appear because of performance problems, not anything else. If you are not sure why an error takes place, try running the test with same profiles and a smaller number of users, and see if the same problem appears.

First of all I should note that there are different types of errors.