Dedicated physical servers are going to outperform virtual servers when it comes to network I/O, disk
I/O, and memory I/O, even in situations where the virtual server supposedly has been allocated more
resources (CPU, disk, and memory) than a dedicated server of similar specs. An important factor to
consider is that in a virtualized server environment, the CPU, disk I/O, memory I/O, and network I/O
have added I/O routing layers between the server OS and the actual hardware. And, therefore, all I/O
operations are subject to task scheduling whims of the host hypervisor as well as the demands of
neighboring virtual machines on the same physical host.
As a real example, a virtual server hosting a database server may have twice as much CPU power as a
cheaper physical dedicated server; however, the virtual server may also have an added 1ms network
latency (a very real example from an actual Xen virtualized environment), even between neighboring
virtual machines. Now, 1ms network latency doesn’t seem like enough latency to care about, until you
consider that a logged-in Drupal page request may involve hundreds of serialized MySQL queries; thus
the total network latency overhead can amount to a full second of your page load time. An added latency
of just one second per page request may also seem affordable; however, also consider the rate of
incoming page requests and whether this one-second delay will cause PHP processes to pile up in heavy
traffic, thus driving up your server load. Adding more and bigger virtual servers to your stack does not
make this I/O latency factor disappear either. The same can be said for disk I/O: virtual disks will always
be slower than physical local physical disks, no matter how much CPU and memory the virtual server
has been allocated.
I/O, and memory I/O, even in situations where the virtual server supposedly has been allocated more
resources (CPU, disk, and memory) than a dedicated server of similar specs. An important factor to
consider is that in a virtualized server environment, the CPU, disk I/O, memory I/O, and network I/O
have added I/O routing layers between the server OS and the actual hardware. And, therefore, all I/O
operations are subject to task scheduling whims of the host hypervisor as well as the demands of
neighboring virtual machines on the same physical host.
As a real example, a virtual server hosting a database server may have twice as much CPU power as a
cheaper physical dedicated server; however, the virtual server may also have an added 1ms network
latency (a very real example from an actual Xen virtualized environment), even between neighboring
virtual machines. Now, 1ms network latency doesn’t seem like enough latency to care about, until you
consider that a logged-in Drupal page request may involve hundreds of serialized MySQL queries; thus
the total network latency overhead can amount to a full second of your page load time. An added latency
of just one second per page request may also seem affordable; however, also consider the rate of
incoming page requests and whether this one-second delay will cause PHP processes to pile up in heavy
traffic, thus driving up your server load. Adding more and bigger virtual servers to your stack does not
make this I/O latency factor disappear either. The same can be said for disk I/O: virtual disks will always
be slower than physical local physical disks, no matter how much CPU and memory the virtual server
has been allocated.