LoadRunner and Performance Center
Showing results for 
Search instead for 
Do you mean 

How To: Understand and calculate Virtual User "footprint"

mtomlins ‎01-14-2009 01:02 AM - edited ‎09-25-2015 02:48 PM

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.




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.


0 Kudos
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 transportation system, a project which captured his natural aptitude for software testing, quality assurance, and test automation. That first test project sought to prevent trains from running into each other -- and Mark has metaphorically been preventing “train wrecks” for his customers for the past 20 years. He has broad experience with real-world scenario testing of large and complex systems and is regarded as a leading expert in software testing automation with a specific emphasis on performance. For the majority of Mark’s career he has worked for companies in a strategic role and used the leading products for performance testing, profiling and measurement. He has also consistently established close ties and relationships with the majory vendors who create these tools. While working as the Technology Alliance Manager at Mercury interactive in 2001, Mark was responsible for developing innovative integrations with cutting-edge partner technologies such as Microsoft .NET, SQL Server and Windows Server, IBM Webshpere, RealNetworks, Adobe Flash, and Citrix. Mark worked for 6 years at Microsoft Corporation as a performance consultant and engineer in the Microsoft Services Labs, in the Enterprise Engineering Center, and in the SQL Server labs. His efforts to foster the success of Microsoft’s top-tier Enterprise customers was focused on their early adoption of Microsoft products as part of mission-critical operations. In 2008, as the LoadRunner Product Manager at Hewlett Packard, Mark led his team in delivering leading innovations for performance testing and engineering.

on ‎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.

on ‎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.


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



on ‎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?


on ‎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.

on ‎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.

on ‎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?



on ‎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?

on ‎06-11-2009 09:39 AM


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

on ‎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.


- G

on ‎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



Mat Villanueva

Payal Dam
on ‎05-25-2016 09:20 PM



I need help on TruClient Web Protocol. I want to know how much memory a TruClient Vuser consumes. I dont see any information regarding TruClient Web Protocol in FootPrint Excel. Kindly help me with my request.

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all