> Not only that, but the behavior of some cases in hardware VMM layers can cause pretty much complete TLB wipes, thus destroying cache coherency and any memory optimizations the web server takes advantage of.
It is certainly true that VMs can have an impact on webserver performance, but the biggest effects are on performance under saturation, rather than peak performance. In my experience, the mean latency of serving typical dynamic applications from a VM isn't significantly higher on a VM than on similarly powered native hardware. This picture changes at high percentiles (the latency of the top 0.1% of requests, for example) but is certainly not catastrophic for the vast majority of workloads.
Of course, if you are running on a soft-scheduled VM on a busy box, or a very small hard-scheduled slice of hardware, then you are going to get bad performance.
But what concrete difference does this have on the price/performance ratio? It's fairly clear from the experiences of several big web companies that the cost of running web servers on a VM is well worth paying in exchange for the lowered costs of maintenance and system management. A good virtualization infrastructure can significantly reduce whole-system TCO for many workloads.
As for the testing infrastructure, the ability to spin up and down test clusters on services like Amazon EC2 is a huge win. The sizes of the instances (slices/vms/etc) should be chosen to minimize the effect of the client VM, but you don't have to go far to remove the measurement effect of running on a VM in most cases.
It is certainly true that VMs can have an impact on webserver performance, but the biggest effects are on performance under saturation, rather than peak performance. In my experience, the mean latency of serving typical dynamic applications from a VM isn't significantly higher on a VM than on similarly powered native hardware. This picture changes at high percentiles (the latency of the top 0.1% of requests, for example) but is certainly not catastrophic for the vast majority of workloads.
Of course, if you are running on a soft-scheduled VM on a busy box, or a very small hard-scheduled slice of hardware, then you are going to get bad performance.
But what concrete difference does this have on the price/performance ratio? It's fairly clear from the experiences of several big web companies that the cost of running web servers on a VM is well worth paying in exchange for the lowered costs of maintenance and system management. A good virtualization infrastructure can significantly reduce whole-system TCO for many workloads.
As for the testing infrastructure, the ability to spin up and down test clusters on services like Amazon EC2 is a huge win. The sizes of the instances (slices/vms/etc) should be chosen to minimize the effect of the client VM, but you don't have to go far to remove the measurement effect of running on a VM in most cases.