Common Issues While Creating Performance Scripts
Common Issues While Creating Performance Scripts
When you start load testing a web site (especially if this is the first load test in your life) you may see a lot of errors in the report. Possibly you will even have to stop the test before it completes, because at some point in time it becomes clear that something goes wrong. If the problem is not so obvious, it is still recommended to check the report for the errors related to each virtual user profile (i.e. to each different type of virtual users) before looking at any performance data.
Issue 1:
Most probably the errors appear because you have not parameterized the HTTP requests in your profile. Note that initially all requests are recorded as is. If user use a recorded profile without any modifications. Performance tool will simply repeat all the same requests with the same values of all parameters. However some values should be unique for each session.
You can check the “Logs” folder for errors and find the first request that produced an error. The goal is to find dynamic session-specific values inside that request. You can do this by comparing different sessions. Usually such session-specific values are contained inside the request parameters, but they can also be passed inside the main part of the URL. When you find such value you also need to find a place (the body of one of the previous responses) from which you can extract it. You can use the “Edit | Find and Replace…” feature for that.
Issue 2:
Let’s imagine that you have done good work on the parameterization and now when you verify your profile, it does not produce any errors, and each new session completes as expected. Now you try to execute a small test with several concurrent users, and you see that it fails for all users except the first one. The problem may be that your web site does not allow several concurrent sessions with the same user credentials. This means that you need to use a different user name and password for each virtual user.
After you make all necessary modifications to the profile you can enable the full logging to check that all user names and passwords are passed correctly. By default logging is enabled only for verification, but if you run test with just few users, you can switch to full logging without any significant performance overhead.
Issue 3:
Even in case the user credentials are passed correctly, you may still see that almost all sessions complete with errors. This may be because some session-specific values still require parameterization, because they depend on the user account. Basically this is the same problem as the first one. I only wanted to note that you may face it again when you switch from one user to many users test.
For example, it may be that each user of your system has a special ID which is passed in some parameter of each request. If you use a different user name, you also need to change that ID. As usual the right value can be extracted from some response and assigned to a variable.
Issue 4:
Your web application may require authentication. This is not exactly the same as entering the user name and password in some form on a web page and clicking the “Sign In” button. When you use a browser to access a site requiring authentication, it displays a separate dialog asking for credentials. Since this is done in a secure manner, it is not possible to record the credentials automatically
Issue 5:
There is one very important rule that you should apply when creating a new virtual user profile: always start recording by entering the landing page URL into the address bar and always delete cookies and browser cache before recording. This is not just a good advice; this is the only correct practice.
If you start recording from the middle of a user session, your load testing tool will not be able to reproduce that session correctly. Even if you click a link on a page already open in your browser instead of manually entering the address, this can produce incorrect recording.
The same will happen if you do not delete cookies. Your web site may behave differently for new users and for returning ones. It may use cookies to restore the previous session. If you record such restored session, you will not be able to emulate a new one.
Finally, if you do not delete browser cache, all requests to cached elements will be skipped on recording. This is the least important problem, because any session-specific requests will be sent in any case, but to create a realistic load you will probably want to load page elements as well.
Important Note:
If you see errors in the report, you should definitely research the problem as described above. However even if you do not see any red lines in the log, this does not mean that everything works correctly. Your web site can produce errors in a “user friendly” manner or just redirect to a different page if it cannot provide valid content for a request containing incorrect parameters. This means that you need to read the actual response to see if it is correct. Again, you can use the “Compare with recorded” function and check all responses step by step.
