Highlighted
Absent Member.
Absent Member.
182 views

Load Generator

I have a basic question on how to use load generator. I have one controller machine + 2 machines to generate load. I am running a total of 200 users across these 3 machines.
1. Is there any maximum limit for the number of users that I can run in one machine?( I have license for 500 users).
2. I have an application where the user login is unique. Will the controller assign user ids for the generators? I mean, I have 5 different scripts. I have around 200 users/script. I have these values in the parameter file. How does the controller handle this? Can you explain how that works?
3. How does Vuser vs transaction work?

Thanks
Subu
0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

Thought you had ONE basic question, not many...

First of all; it is not recommended to use your controller as load generator. if the controller gets overwelmed by the load,then your results will be skewed and will not be reliable.

1. Is there any maximum limit for the number of users that I can run in one machine?( I have license for 500 users).

Answer: Nope, there is no such thing as an equation to calculate this; this is a trial and error process. Ramp up the number of vusers and see how many it can handle each load generator. usually, you don't want to go over 70-80 CPU usage on this machines;

2. I have an application where the user login is unique. Will the controller assign user ids for the generators?

Answer: each Load Generator will get its own copy of the data files (userID/passwords). Both load generators will be using the same data from different copies. Load Generators cannot talk to each other. E.G Vuser 1 in Load Gen one will user userid1 and the Vuser1 in the load gen two will start with userid1. If you want each vuser to use unique data, then provide different data for each load generator and configure the runtime settings for the vusers to use unique data.

I mean, I have 5 different scripts. I have around 200 users/script. I have these values in the parameter file. How does the controller handle this? Can you explain how that works?

The controller does not handle any test data; it only sends the scripts to the load geneartors along the data files. this means that all of the 5 scripts will get an individual copy of the same data file; unless, you set up the scripts with their own and unique data files.


3. How does Vuser vs transaction work?
What do you mean by this. Not making any sense.


hope that helped....


~hector
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

Good morning,

What is meant by this statement:

"you don't want to go over 70-80 CPU usage on this machines";
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

that means that your load generator should never be running above 80% CPU usage. So allocate or assigned x number of vusers to each load gen up to the point where the cpu will be below 80% utilized. Once at 80% or above, then stop rumping up for that load generator.

thanks


~hector
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

Thank you. Is this information supplied in any documentation?
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

Nope, No documentation on this.... Just know it from experience.... Ultimately, it's up to you to decide how many vusers will be assigned to each load gen, just make sure your don't overload the generators.

thanks

`Hector
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Load Generator

1. It depends on the application being tested and the protocol used, and the computer specs. Just make sure you are not reaching your CPU and RAM limits. It is also best to login users over a period of time. We noticed CPU spikes when we have multiple users logging in.

2. In the parameter set-up, make sure 'Select next row:' is set to 'Unique'. This way each user (no matter which load generator it is on) will get a different user id.

3. Not sure what you mean
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.