Quick Start Guide

In order to minimize your learning curve we recommend taking a look at WAPT Quick Start Guide (PDF, 3.1Mb). This document describes step by step how to create a simple but very typical test scenario for a web site, launch the test and interpret its results.

An example of WAPT Pro usage: this demo clip (download MP4 for maximum quality: WAPTProVideoTutorial.mp4 - 108Mb) shows step by step how to design a test with different types of virtual users, perform load testing of a web application, and interpret the test results.

Transcript

Our work starts with creating a test scenario. WAPT Pro has a special Wizard for this.

We will emulate two types of site visitors in our test. One will only browse the site and another one will buy items.

For each type I will create a virtual user profile. Let's start with the browsing user first. I launch the recorder and enter the web site address.

Now I do step by step everything that should be emulated in the test for this type of user. WAPT Pro records all HTTP requests generated by my web session.

When it's done, I click the "Stop Rec" button and let WAPT Pro process the recorded content.

Now we see that the recorded sequence of HTTP requests has been added to our profile. Some of them were converted to page elements, so the total number of page requests is smaller than we saw during the recording process. Let's select one of the requests in the left view.

On the "Properties" tab we can see the list of parameters.

Now let's see how it works. I am going to verify the test. This is done by executing one full user session with our profile.

During the verification we can see the report. It contains the HTTP response codes and other information. If we had any errors, we would need to fix our profile before launching a test with it. For each reply code we see the number of pages and page elements returned with that code.

As we do not see any errors, I can set the baseline response times. This will let us see the performance change when the site is under load.

Now let's take a look at the profile execution log. It is very useful for checking if a profile works correctly.

Let's save our scenario. All current profiles (we have only one for now) are saved at the same time.

Now let's record a different profile for a user that will buy.

I perform all the actions of the user whose behavior we want to emulate while WAPT Pro makes the recording.

We are done.

Now let's verify the profile.

The verification has failed. We see some errors. Let's find the reason of the problem in the log.

The last response was returned with the 403 code.

Let's check the previous requests one by one. We see that the cart is empty, while it should have contained the purchased item.

Usually the root of the problem is found in the earliest request with an incorrect response.

Let's check all values contained in its parameters and URI.

I think that there is a session-specific value here.

I need to replace it with a variable to make it correct in each emulated session.

Most probably this value is created by the server. Let’s compare the response to the previous request with the originally recorded page.

We see that the suspicious value has really changed in the verification session. This confirms my guess that it is session-specific. The page contains a number of occurrences, including a hidden field of an HTML form.

WAPT Pro creates variables for such values automatically.

So, we only need to use the corresponding variable.

There may be other occurrences of the same value. I use search to find and parameterize them all.

Now let's see how the profile will work now.

Looks like it has passed this time without errors.

Now let's take a look at the profile execution log.

We see that the profile works correctly...

and a new order was created successfully.

Our profiles are ready for the testing. Now we need to set the general test options. Here I specify the test duration and the type of load.

I choose "Ramp-up". This means that the number of virtual users will be increasing during the test.

I choose initial and final number of users and how fast that number will grow.

Only 5 of our site visitors will buy items, which is in line with our expectation for the real life customers.

On this page I specify log settings. Let’s create full log only for the first user of each profile.

Finally, I need to select load agents that will execute the test.

Now everything is ready. Let's run the test!

Shortly after starting we see the first results on the Summary Graph page.

WAPT Pro adds new data to the chart in real time.

There are several tabs with graphs.

If I switch to the "Summary Report" view, we will see that report data is also updated in real time.

Here we can monitor the number of sessions, page requests, hits, active users, etc.

Let's switch back to the "Summary Graphs" view.

Waiting for some more time...

We see that starting from some test phase the number of pages per second does not grow even under increasing load. This means that the server cannot process more requests.

Average response time starts to grow correspondingly.

Waiting for some more time...

Let's check the errors.

We see that the error rate has grown up to 50%.

The load has reached the maximum volume. As we see here, the performance of our site has degraded even more.

Let's check the errors.

The error rate has grown sharply.

The number of failed sessions has become very high as well.

Let's wait for the test completion to see final results.

Now the test is finished and I can perform some analysis.

I can change the scale to choose between more detailed data and more averaged values.

We see that the average performance of our web site was about 1.6 pages per second throughout the test.

The average response time was growing together with the number of virtual users participating in the test.

Let's take a look at the report.

The test is marked as "failed". This means that one of the pass/fail criteria indicated a failure. Let's try to get more details.

It appears that the site worked correctly only in the beginning of the test when the load was small. Since a certain moment all sessions started producing errors.

By default WAPT treats failed all tests with error rate higher than 1%.

So, our test has obviously confirmed that the site does not meet this very general industry standard during the high load.

We can also estimate its performance limit: the number of users that the site can handle.

Let's try to find the exact reason of the failure.

The server responded with a 503 HTTP error to some requests.

More details are contained in the logs.

Several sessions in the beginning of the tests completed successfully.

However we see the error message inside the response body in subsequent sessions.

Overall our web site is able to serve only about 2 page requests per second. It appears to be its limit for any number of users.

We see that the average response time grows together with the number of virtual users participating in the test.

When we have 30 or more users, every one of them faces a problem.

The reason of the problem is the SQL server component. This means that if we want to improve the performance of the whole site, we should change the SQL server hardware configuration or tune its options.