Profiles, Iterations, Users, Sessions... Clarification

[niekell 0]

Hello WAPT Folk,

 

We've been using WAPT for a few years now to load test some critical business applications and though there have been bumps in the road along the way we now have a working knowledge of how to configure the tests to evaluate performance and stress. However I would not say we are experts at using WAPT by any means.

I want to check that our understanding of the interaction between Profiles, Iterations, Users, and Sessions, and then ask a question (actually request a new feature) related to that understanding.

 

Profiles - a recorded set of web pages visited using either the inbuilt browser or an external one. Previously Profiles were composed of an Initial, Main, and Final part. These parts have been superseded with the advent of a Loop part, this allows sequences of web pages to be iterated through but does not limit the Profile to one part which has Iterations.

 

Iterations - When there was a Main part, it allowed iterations of itself to occur which simulated a cycle of web page visits until the Iteration count was reached then the Final part was run. Now that there are Loop parts you can iterate multiple times in multiple Loops per Profile. Nice addition.

 

Users - There are various meanings for this as they can be implemented various ways. I'm just going to cover the one we use as a standard, Basic Authentication against an Active Directory system. In the Properties of a Profile we check the Authentication checkbox and using the "Users and Passwords" button we load a text file with user information in it. The text file has a username then tabs to a password, this is a tab delimited text file with one set of "credentials" per line.

Now on to how WAPT makes use of these Users. When a Profile starts its load test, lets say it does a Ramp-Up of 4 Users ever 3 seconds of 1000 Users and it takes a minute for a single run through of a recorded Profile to complete for a single User. From 0-60 seconds 160 Users end up beginning and executing their first run (Session 1) of their recorded Profile. Then when we get to 63 seconds into the test, the first three Users have finished their first run (Session 1) of their recorded Profile, so they begin Session 2 (their second run through the Profile, all parts, all loops, all over again). This means I would never get more than 160 Users active at one time, never have more than 160 Users logged in, and most critically for us never attempt login for Users 161-1000.

This is a problem as there are times when we're not so much interested in performance or stress as we are robustness of the application we're testing. When using large User sets, some of our Users have data which is fetched during the execution of the Profile which causes errors and by running them through the WAPT Profile we can identify Users whose data is non-compliant with our standards and either code to handle it, or get the data corrected. This is an important component in making our web applications provide a robust User experience.

 

Sessions - The number of times a specific User executes the recorded Profile.

 

My question, really a feature request, is that WAPT allow some mechanism to limit the User's Sessions. MaxSessionCount?

Perhaps near the "Break user session on errors" and "Wait [1] seconds after session failure" options in the Advanced section of the Properties of the Profile?

 

Best wishes, Paul.

Senior Software Developer

University of South Australia

[sergei 0]

Users - There are various meanings for this as they can be implemented various ways. I'm just going to cover the one we use as a standard, Basic Authentication against an Active Directory system. In the Properties of a Profile we check the Authentication checkbox and using the "Users and Passwords" button we load a text file with user information in it. The text file has a username then tabs to a password, this is a tab delimited text file with one set of "credentials" per line.

Now on to how WAPT makes use of these Users. When a Profile starts its load test, lets say it does a Ramp-Up of 4 Users ever 3 seconds of 1000 Users and it takes a minute for a single run through of a recorded Profile to complete for a single User. From 0-60 seconds 160 Users end up beginning and executing their first run (Session 1) of their recorded Profile. Then when we get to 63 seconds into the test, the first three Users have finished their first run (Session 1) of their recorded Profile, so they begin Session 2 (their second run through the Profile, all parts, all loops, all over again). This means I would never get more than 160 Users active at one time, never have more than 160 Users logged in, and most critically for us never attempt login for Users 161-1000.

This is a problem as there are times when we're not so much interested in performance or stress as we are robustness of the application we're testing. When using large User sets, some of our Users have data which is fetched during the execution of the Profile which causes errors and by running them through the WAPT Profile we can identify Users whose data is non-compliant with our standards and either code to handle it, or get the data corrected. This is an important component in making our web applications provide a robust User experience.

 

If you have loaded 1000+ username-password pairs you will have 1000 different users at the end of the test. WAPT calculates a number of username-password pair for particular user as a rest of dividing usernumber on number of pairs.