How To: Understand and calculate Virtual User "footprint"

One of the most common questions we get about LoadRunner Virtual Users relates to the resources required to execute the scripts on the Load Generator.  One advantage of the maturity of LoadRunner is that we have supported so many different drivers and protocols and environments over the past 2 decades.  We've learned so much about how to give a more detailed response to really advise users on how much Load Generator resources will be required to be successful.  You might imagine that the answer isn't black & white or even close to a 1 sentence answer.  Here are some simple ideas that can help you determine how to configure your Load Generators.
 
For Memory: each protocol has different parts that affect how much memory is required, so there is no single answer across all virtual users - Web is different RDP, which is different from SAP Click & Script, which is different from RMI-Java.  Some vuser types have external drivers (like ICA, RDP or SAP) so the guidelines didn’t include the footprint for the external executable driver. The Click & Script vuser types really can confuse you, because these seem like new versions of old protocols...but that's not actually true - the C&S protocols are completely new architecture, but more than anything, every vuser’s memory foot print is GREATLY impacted by the following factors:

  • the size of the driver library (this is fairly static)
  • the # of lines of code included in the recording (varies greatly by customer)
  • the # and size of parameters included in the recording (varies greatly by customer and script type)

 
For CPU: of course, each driver has slight differences in CPU overhead, but for the most part they are all very efficient (and - yes, we will continue to improve Click & Script to be better!!) the amount of CPU used on a LoadRunner load generator will vary by the following factors:

  • iteration and pacing, which controls how “active” the vuser is (varies greatly by customer)
  • stress testing scenarios usually use more CPU, as opposed to real-world testing which has slower vusers (but more of them)
  • customized code or extra script processing (like string manipulation, or calculations) will chew up more CPU

 

For Disk: the main thing here is logging, the more customers increase the details and amount of logging the more disk will be consumed external parameter files (writing or reading from individual vuser threads) will really hammer local disk some vusers with external driver executables will have additional logging of their own, or caching of content.

 

For Network: the result of multiple virtual users running on single load generator is a concentration of all those vusers network traffic on single NIC the payload of network api calls varies greatly for each and every different application stress testing (e.g. fast iteration pacing, no think-times) could easily result in over-utilization of NIC bandwidth

 

When it comes to calculating your virtual user footprint, it's actually quite easy.  But first, let me tell you that not everyone should need to do extensive calculations of the virtual user resource utilization.  This is important *only* when you have a very high number of virtual users or a very limited number of Load Generators.  The basic approach is to run a preliminary test with just 1 script, while you measure the resource utilization on the Load Generator directly.  You are specifically interested in the mmdrv.exe process on the Load Generator, which is LoadRunner's primary multi-threaded driver.  Measuring the private bytes reserved by this process for 1, 2, 3, 4 then 5 then 10 virtual users will give you some clue as to how much memory is required by each additional virtual user added.  Simultaneously you should monitor CPU, Network and Disk just to determine if there are any excessive utilizations.

 

mmdrv.jpg


It is important to note that you should be gathering information about the performance of your script running on the Load Generator - using the same run-time settings that you will use during the full scenario run.  If you are stress testing with very little think time or delay, then you'll want to use those same settings.

 

Labels: LoadRunner
Comments
(anon) | ‎02-06-2009 02:45 PM

Information about  the footprints for Vugen is good. this will help me for future performance testing environemnt.  I would also appreciate if you put some light on calculation of Pacing between two iteration.


(anon) | ‎02-18-2009 06:03 AM

Hi Mark.

There was a question that I had related to the Memory footprint of the LR 9.1 sheet, which is pasted at this location.

forums13.itrc.hp.com/.../questionanswer.do

The question is why is the CPU usage for the medium script higher than the simple script

                                                              Vusers          CPU%

WEB (Http/Html) High 50 3.1

WEB (Http/Html) Medium 50 12.5

Thanks.

Krishnakanth.pps@gmail.com

| ‎02-18-2009 08:52 AM

Hi Krishnakanth,

I must admit that the creation of that old "vuser memory footprint" document was before my time here as the PM for LoadRunner.  If you comprehend the this blog entry (above), you will find that it is more important for you to learn how to calculate the memory footprint of your virtual users as you have built them for your test rather than to simply have a chart of static data for "empty vuser" comparisons.

What good is it to know the memory requirement for an "empty" virtual user that has no steps, actions, parameters or data?

-mt

(anon) | ‎02-18-2009 04:32 PM

Hi Mark

Thanks for the info. Another question. Is it possible to know the number of Vusers a particular protocol for a standard NT machine. A rough number, because, I am sure you understand, it would not be possible to do a research for a number of users for each and every protocol.

(anon) | ‎02-24-2009 04:28 PM

I used to do this a lot when I did Java (general template) doing a Java RMI app testing.


It helps in wedging in every Vuser you can into memory and determining your available CPU so that you can create a repeatable test that you do not have blame your load generation for creating problems.


I also found that if you are writing custom code, characterize mmdrv footprint overtime. It may help if your script varies in memory consumed. You may also find you wrote inefficient code that needs to be corrected. It can be very important if you are near the memory limit on your generators and you have a 1000 vuser group that varies in size by 1MB over time. It can be enough to crash your test.


Fortunately I never had that issue because I spent a lot of time characterizing my memory footprints before running them in a large scenario. Especially soak tests. It is definitelty worth the extra effort.


dmennicucci | ‎03-11-2009 08:09 PM

Hi Mark,

We have noticed that when running LR, that the memory usage does not flat line after all of our virtual users are ramped up into our sys for tests, as we had expected. Instead the injector resources specifically memory continue to get consumed as steadily as virtual users ramp up and after all users are logged in and performing their actions for the test. Can you explain?

Thanks

DM

(anon) | ‎03-25-2009 08:44 PM

I am looking to procure HP LoadRunner license to conduct performance/stress testing.  If I want to simulate up to 2000 concurrent users, what level of licensing do I need to procure.  How does virtual user license relate to simulated concurrent users?

(anon) | ‎06-11-2009 09:39 AM

Mark,


I am new to LoadRunner and trying to understand more of its capabilities. Is there support for testing/evaluating over wireless networks like WiFi, WiMAX or 3G?


- Jigar

(anon) | ‎09-15-2009 09:07 PM

Hi Mark,

Great Info Thanks.

Would the number of VUSERS on a Load Generator cause Response Time variations. Also will the load on the VUSER have an Impact on the Response time ?

I am sorry if these questions are naive.

Cheers

- G

mat_villanueva | ‎09-15-2010 06:32 PM

Hi Mark,

 

1.)    We’re planning to simulate 1000 vusers for SAP system; do you guys have ideas on what specs or how many Loadrunner machines we need to cater all 1000 vusers for SAP?

2.)    I tried running a test using a single load generator for 150 vusers in SAP (LoadGen specs: 4GB RAM / 20GB Hard disk), what happen is when I hit 80 vusers suddenly all others vusers are getting failures (by this time, the memory utilization of the LoadGen is around 3GB), the common error I’m getting is ‘Abnormal termination, caused by mdrv process termination’. My question is do you think the error I’m getting is due to memory outage? If not, is there any other way I can prevent this from happening?

 

Your response will be very much appreciated

 

Regards,

Mat Villanueva

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Mark Tomlinson is a software tester and test engineer. His career began in 1992 with a comprehensive two-year test for a life-critical trans...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation