Cadet 3rd Class Cadet 3rd Class
Cadet 3rd Class
960 views

Calculating VUsers

Jump to solution

We watched the video that 10 VUsers not enough, but what does HP recommend? What formula do they recommend to use to calculate the number of vusers required to simulate X numbers of transactions per hour or based on other data. Certainly there should be ways to simulate higher load than number of Vuser licences purchased.”

Thanks

0 Likes
1 Solution

Accepted Solutions
Absent Member.. Absent Member..
Absent Member..

I'll echo others and agree that Transactions Per Second is the primary metric, if one has to choose.  If number of vusers available/licensed is an issue a corner can reasonably be cut in terms of active vusers on the system vs. number of active users on the system.

 

However, the risk you run in doing that is that you're not utilizing all the resources that a logged in user will take in production.  If I recall correctly the "you need more than 10 vusers to run a load test" video points this out.  

 

The bottom line is that performance testing is and always will be an exercise in approximation.  How many vusers should you use?  Which business processes should you model?  How variable should your traffic patterns be?  These questions and hundreds more are where the art of performance testing creeps in on the science.  

 

The best way to approach it is to address the most important parts of the most important questions and gradaually work your way inward to a less "artistic" and more scientific approach.  You'll very likely never get to every task you'd like to but in pursuing perfection you'll give your client/employer more and more accurate tests and less and less risk.  

View solution in original post

0 Likes
4 Replies
Absent Member.
Absent Member.
That should be straight forward. Suppose your script is doing 10 transaction/1 minute. That means 1 vuser will produce 600 transactions in 1 hour. Now, in order to achieve X transactions in 1 hour, you will have to use X/600 vusers.
LR R&D
0 Likes
Absent Member.. Absent Member..
Absent Member..

What you are asking is really not a tool question but a general load testing methodology question and therefore it really isn't for HP to dictate how you generate your load.

 

I would suggest that there are many ways to skin this particular cat and that you can certainly generate far more transactions with virtual users so that you are simulating far more traffic\transactions than the number of virtual users you are using would indicate.

 

As for how do you know how, there are many ways to learn your systems current usage.  Activity logs, database examination, existing documentation from the different teams involved.  When I first started working in performance testing we would do visual monitoring of the teams who use the software that we needed to test.  We would collect steps for the scripting and we would use a stop watch to monitor how long certain tasks actually took the user to perform.  From that you can multiply the number of actual users by the number of hours per day and get an idea of the number of transactions that we needed to simulate.  Follow this up with verifying that the number of transactions\updates are represented in the database and you now have your transactions per day.

 

Now you can develop your script and using a combination of ramp up, think time, total execution time, and ramp down you can target a total number of transactions that your can accomplish with what ever number of virtual users you have.  If you start fast, have no think time and execute for a long period of time you could possibly simulate the number of transactions with very few total virtual users.  This is as I said just one way to skin this particular cat and not necessarily the best way for you.

 

You may not be able to script every possible transaction so you may need to overload transaction a because you don't have time to script transaction b or c.  This is a risk but one that performance testers have to take because you are rarely given enough time or money to script 100% of your application.  So how do you decide if you script a, b, or c?  Again every organization is different and you may make some mistakes and you test transaction A and after 2 months in production you discover that transaction C had a memory leak and causes the application to crash after 2 weeks.  Is this a failure of the performance testing?  No it is a failure of management for not providing enough time and funding to test everything.  In the future however you may learn that the performance tests should have chosen to pick transaction c instead of transaction a beaus it was more critical or maybe it had more actual users long term.

 

What types of testing should you do? I recommend the following

 

  • Traditional Load Test.  Trying to meet the total number of transactions per day in a focused period of time.  Using think_time to ensure that the vuser is as close to real user load levels that you can achieve
  • Stress Test.  Add users until the system breaks
  • Stress Test.  Test at 75 - 80% of your anticipated load for extended periods of time
  • Break Test.  Remove all think times and try to pound the system as hard and as fast as you can for as long as you can.

There are many more types of tests. All of them have their purpose and each has their limits and concerns.

 

If this seems like a  lot of work, it is.  This is a very specialized specialty within the testing organization and it takes a lot of time and patience to get it right.  Hopefully you didn't get LoadRunner with the intention that it would do everything for you.  LoadRunner is a just a tool.  Performance Testing is a science that you will have to master to get the most our of the tools you have at your disposal.

 

Hope this helps.  Good luck on your journey to becoming a performance tester.

 

Craig Drummond

Premier Support - Technical Account Manager

 

Absent Member.. Absent Member..
Absent Member..

Also, I would add that Number of Users is a poor metric to use since it is so subjective and is not very descriptive of load.  A more effective descrition of load is transactions per second (TPS).  You can pass most any test with a set amount of concurrent users by increasing the thinktime so focus on other metrics when determing load such as TPS, Hits/sec, Throughput, or any other metric particular to your application. 

0 Likes
Absent Member.. Absent Member..
Absent Member..

I'll echo others and agree that Transactions Per Second is the primary metric, if one has to choose.  If number of vusers available/licensed is an issue a corner can reasonably be cut in terms of active vusers on the system vs. number of active users on the system.

 

However, the risk you run in doing that is that you're not utilizing all the resources that a logged in user will take in production.  If I recall correctly the "you need more than 10 vusers to run a load test" video points this out.  

 

The bottom line is that performance testing is and always will be an exercise in approximation.  How many vusers should you use?  Which business processes should you model?  How variable should your traffic patterns be?  These questions and hundreds more are where the art of performance testing creeps in on the science.  

 

The best way to approach it is to address the most important parts of the most important questions and gradaually work your way inward to a less "artistic" and more scientific approach.  You'll very likely never get to every task you'd like to but in pursuing perfection you'll give your client/employer more and more accurate tests and less and less risk.  

View solution in original post

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.