CODEWITHSUNDEEP
testingvirtual-machinevmwareload-testingstress-testing
Daniel
Daniel

Reputation: 631

Load testing against web application installed in VM

As everyone knows fixing hardware specs for webapp installation point for loading testing is as important as finding good metrics to address the testing purpose. However, the reality is there isn't an available physical machine that i can leverage with, which forces to find alternative solution - a virtual machine.

Fortunately, my company uses vmware (ESXI) and I am grateful that I can have access to it. But when I attempt to create a VM for myself, it seems that I am not even able to tell the actual hardware spec. of the VM I was going to create, so it's kind of hard to map back to the kind of physical machine i am simulating for.

Does this really matter to load testing? Word of advice will be appreciated

Thanks

Upvotes: 1

Views: 1160

Answers (2)

Nat
Nat

Reputation: 14305

Yeah, it really matters for load testing.

Without the an architecture to test against, you cannot verify that your chosen architecture will support the planned application load.

However, you can figure out the response times of different pages relative to each other. You can get some stats on what the virtual machine says it is doing and if you are nice to the owner of the hardware, can gather some stats from the base hardware running the VM.

You can also measure the relative differences between pages in your site. So load testing on the VM is not a complete waste of time, but is not comparing apples with apples if you intend to install on a physical machine in production.

Upvotes: 2

James Isaac
James Isaac

Reputation: 11

The great benefit of virtualization is that you don't have to care about what kind of hardware you are running on - the VMWare layer lets the server admins move machines around from one hardware platform to another without the application or users knowing anything about it. From your perspective, however, this is a disadvantage, since you aren't exposed to the underlying hardware and therefore can't know what you have. There are many ways that the VM admins can mask or even limit what resources are available to you. For example, you can "see" a dual-core, 2.33 Ghz processor, 2 gb of RAM, 100 GB of hard disk VM, but what you don't know is that behind the scenes your server could be throttled so that it will never use more than 33% of the available CPU resources. On the other hand, your VM admins could build a policy that reserves resources for you so that on an 8-core VM host, your 2-core server is guaranteed two cores at all times - i.e., 100% cpu availability for your server. Without knowing what the VM policies are, you really can't map to a physical server's characteristics. The best thing would be to spend half an hour with your VM admins, getting them to tell you everything about their virtual host infrastructure. They'll probably enjoy telling you all about the reservation policies and scheduling, if they have spent any time crafting the resource pools.

Inside your guest VM, you should be able to tell some things like what the processor family is, whether you have one or two cores, how much memory is available, etc. Take into account the feedback from the VM administrators - if they say that your VM is in a resource pool with other servers and will only have 50% of the total available server CPU resources, then that may help you extrapolate out. Try running your load at 8 PM or 3 AM to see if you get different numbers than what you see during the day. Maybe they can give you a reservation for CPU resources if you promise to only run your full-out testing after business hours.

Now, as far as testing goes, it's a "valid test" scenario if the goal of your testing is to find out where your application bottlenecks are. You have been given an arbitrary constraint, and your tests will determine whether you need more memory, more CPU, more disk i/o. You can tweak your application from there.

Hope this helps - James

Upvotes: 1

Related Questions