* Busy Loaded system and idle VM/CT* Busy Loaded system and busy loaded VM/CT

Described benchmark case is common for many This workload simulates latency sensitive real life application which receives an event through the network and have to respond. Such workloadsare very sensitive for CPU scheduling algorithms and work best when interactivity is taken into account. For exampleExamples of such workloads: high performance computing, image processing and renderingenvironments (which introduce small synchronization messages), web and database servers and so on.

To measure response time we use a well known netperf TCP_RR testis used which measures how many round-trips a message can do between 2 hosts. To emulate busy add a load in VM/CT we run simple CPU eater program hog application (doing a busyloopand nothing else) inside of itis started. To emulate busy loaded system we run several busy loaded VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' of VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

Hardware* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM* Network: 1Gbit direct server<>client connection

ClientPlatform: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM Network: 1Gbit direct server<>client connection * Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64 * Guest OS: CentOS 5.5 x86_64

* '''In all the three cases (1 - idle system and idle VM/CT, busy 2 - loaded system and idle VM/CT, busy 3 - loaded system and busy loaded VM/CT) OpenVZ show shows the lowest overhead over all the tested virtualization solutionsand demonstrates latencies close to the native results of non-virtualized systems.'''* '''VM virtualization solutions (like Xen, ESX) demonstrate latencies by an order of magnitude worse then native response times and introduce ~700-3000% overhead.'''