On 11/09/2010 10:59 PM, Bill Davidsen wrote:
> On 10-11-09 11:49 AM, Dennis Jacobfeuerborn wrote:
>> AFAIK there are some issues with that benchmark not being free.
>> What I'm basically looking for is a simple comparison of a few key metrics
>> between common setups. For example a simple bonnie++ run on XenPV and
>> KVM+virtio_blk could already give people at least some baseline numbers.
> I'd be happy to run some benchmarks. I've got some identical (if humble)
> machines... Would you want just a Xen vs. KVM? If so, what parameters or
> setup options would provide the best apples to apples comparison?
> The machines are;
> - quad core athlon II x4
> - 4gb ddr3
> - 1x 7200rom 500GB drive
> - Fedora 14, stripped (but identical) installs
> If these are too low end for useful results, let me know. Otherwise,
> I'll fire up Xen under Michael's 2.6.32-25-172 kernel with the stock
> 4.0.1 hypervisor on one machine, and can use the stock KVM/QEMU setup
> for another.
> Assuming all is fine, would it matter whether the VMs were F14 vs CentOS
> I was thinking 3x runs each of;
> - bonnie++
> - Recompile Michael's kernel
> - ?? Please make suggestions
Thanks for the offer. The services which have in the past shown significant
differences (my experience) are small, with lots of connects and io.
Examples are NNTP (ak usenet news) and POP mail servers. I suspect that
DHCP and DNS have too little io to show the effect, but I never had enough
load to know. Unless web service has a lot of dynamic content, I doubt it
would have enough load to show the difference unless someone has server
image and load generator to use. I could probably dig up a simulated load
for NNTP, but I don't have an easy way to preload a server. My days of
generating test loads were when I ran ISP NNTP servers and only had to
provide test loading against the servers.
I think these application level benchmarks should be considered second
tier/optional because it's difficult to get realistic numbers for these.
When I'm looking for benchmarks I'm usually mostly interested in low-level
ones because they are more easy to apply to my current situation.
If I run the mysql benchmarking suite then the results may or may not be
indicative of what my app is actually doing. In comparison seeing that
Hypervisor A has only 50% of the random-i/o performance of Hypervisor B
then that can give you a good ballpark figure for all your applications
depending on how dependent they are on random-i/o access.
In the networking case I would rather opt for a plain TCP/UDP benchmark
that measures throughput and latency (and maybe connections per second) as
these numbers are useful for people running any networking service.
As for OS and hardware configuration I think it's more important to get at
least one run on each Hypervisor on the same os/hardware combination to
make them comparable. I'd obviously prefer RHEL/Centos since that's what a
lot of people run on their servers (including me) but I think Fedora would
work just as well to at least get performance comparisons of the
hypervisors relative to each other.
One important bit would be the parameters for the virtual machines as
things like for example the cache configuration can have a great impact on
the outcome i/o tests for example.
Performance aside, There is still a lot of old or small hardware that
can't do KVM at all, and which are easier to administer with a VM which can
But how important is a benchmark in this case? If you want to move them to
new hardware then you'd buy a machine with hardware virtualization support
anyway and if you can't run the VM on new hardware then you probably should
just run it on xen as you don't have a lot of options anyway.
I hope I'll eventually get my hand on a server that doesn't have to go into
production the same day it is delivered so I'm certainly interested in
participating but right now I could only deliver comparative benchmarks
from desktop type systems and my new dual core intel 4gb 7200rpm drive
notebook. Only really useful to pitch the hypervisors against each other in
relative terms but the more data the better right?