1. Minimum 1. Maximum is determined by the resource fingerprint of your virtual users with 20% headroom on each of the finite resource pool elements. Short way of saying, "your mileage may vary." 2. The controller is lighter when compared to the other components, but it would be run on a dedicated host from the load generators. If we take some rule of thumb guidelines and make note that the controller is a 32 bit application and can address (as a result) at the most 4 gig of memory (2^32 address space), then I would recommend a minimum of 2GB for a healthy OS dedication and then the other 2GB for your application space. If you have a 62 bit OS and you are running your controller in the WOW32 address space then go head and give your host 8GB so you can tear out a full 4GB for the WOW32 subsystem when it starts or it it needed 3. There is a process question and a resource question embedded here. I look to a minimum of three load generators in any condition. Two are for primary load and one is for a control set, running a single virtual user of each type. All load generators are hardware matched. This is in addition to the controller node. So, you're looking at four nodes as a minimum test set, on a process basis. Having noted that, depending upon your virtual user type and your resource fingerprint for your virtual users, your load generation need could range anywhere from the three load generator minimal set to requiring as much as a single OS instance per virtual user, which would then be 1500 load generator instances. Without knowing your virtual user types and the precise resource fingerprint of your virtual users the answer becomes almost impossible to answer correctly. Take advantage of your primary foundation skills to profile the resource usage of 1 user, then 5 users, then 10 users, then 50 users on a load generator and project out that curve. The curve is not linear and is impacted by the number of users as multiple mdrv instances may need to be kicked off to support a particular user load.
