• SPEForums need your contributions to build up a strong repository of performance engineering resources.

Hi all, I am new to performance testing. I...

V

Vidya Iyer

Guest
Hi all, I am new to performance testing. I want to know how many load generating machines will be required if we want to perform a load with 3000vusers?
 
you have to understand memory footprint before deciding.. first decide which protocol you are using, then analyze memory foot print for each vuser, then analyze hardware of LG.. then you can estimate the no. of LG's required for 3k vusers
 
Three load generate enough each one can support 1000 V users.
 
Measure the resource fingerprint of your users, leveraging your non tool specific foundation skills in monitoring and systems analysis. As you are new, unless you are bringing with you a decade or more of Dev experience, your users are likely to be resource heavy in terms of how much CPU, disk and ram each user consumes on the load generator. Your type of virtual user also comes into play, with some protocols naturally lighter in resources due to their location lower in the stack. On a process basis you will need a minimum of three, two for primary load and one for a control group. Outside of that, depending upon the size of your virtual users and the size of your load generators you may need as many as 3000 operating system instances to run 3000 users, at one user per OS instance
 
A vuser consume around 5-10 MB of memory. To add to this you can probably check the mmdrv process which is consuming memory..... Based on that you can manipulate the user load.....Again as mentioned above by James you need the figure that out what's the best suitable config.
 
Side note> You are new to performance testing You are engage in a performance test with 3000 users There is significant financial risk here if a site must be performant for 3k users. As a new performance tester you should not be asked to run such a testing effort. It is setting you and the project up for a great unpleasantness. You should have a very mature performance tester allied to this effort and you should be riding shotgun trying to absorb as much as possible from the master in the field
 
Depends the protocol from your scripts and the injectors capacity, some time ago I was execute a test scenario in to a corporative intranet around 8 countries in Latin America with 8 load inyectors sending in a Web protocol only navegation.
 
Also please keep in mind how mdrv.exe works internally as well since it's your driver process and it will be spawned off via the controller with some amount of threads inside each instance. Past that keep in mind how efficient your injector OS is at process and thread scheduling as well as how your tcp/ip stack will be processing the communications as well. Some nics can handle 1000+ sockets nearly simultaneously and some/many/most simply can not keep up no matter how fast the main buss is that feeds it. Interrupt handling will also play a major role here as well. The calculations get a bit trickier as well if you are using virtual LG's on top of everything else too. With that said I once crafted a very specific scenario that ran on 2 Dual PIII 800 Compaq DL360 G1 servers with 4gig of ram - 1500 vusers per with no measured bottlenecks or response time differential due to the acutal injectors. This required nearly 40 registry tweaks to the Windows 2003 os on tcpip/scheduler entries, as well as a very clean and non loaded network switching environment infront of the sut. It can be done but definitely baseline as per Pulley's suggestion too. Without that you have no idea which is is affecting your transaction outcomes. Injection load methodology, injection infrastructure, SUT infrastructure, or SUT application algorithmics.
 
James is right in both of his comments. A 3000 vUser test is probably something that you'll need some help with. I see that you work for Accenture. Ask your managers if you can "buddy up" with a more experienced colleague to ensure that you can learn on the job whilst reducing the risk to your client of delays to the testing process.
 
You must log in or register to reply here.
Back
Top