Yes, virtualization is faster (sometimes) than native hardware

Yes, virtualization is faster (sometimes) than native hardware

Summary: Three studies show that in some circumstances VMware vSphere can deliver faster performance than native computing.


It's a computing truism that when it comes to delivering the fastest possible speeds with high-performance computing (HPC), you must use native computing instead of virtualization. Recent studies have shown that, in some configurations, VMware's vSphere can actually deliver faster performance than native computing.

Believe it or not, with the right tuning, architecture, and workloads, some jobs will run faster VMware vSphere virtualization than native systems.

In one recent study, which will be described in detail at VMWorld in San Francisco in late August, Edmond DeMattia, Senior Virtualization Architect at Johns Hopkins University's Applied Physics Laboratory, will show how a vSphere implementation delivered better results than running on native hardware.

DeMattia found, while running large-scale, Monte-Carlo simulations [a kind of mathematical risk analysis], that the resources of independent Linux and Windows HPC grids when bound together into a 2,720-core, fully virtualized, HPC platform decreased run-times by an order of magnitude and in one specific use case realized a 2.2-percent performance increase over its native hardware configuration.

This isn't the first such study. In 2009, HP ran some benchmarks in which vSphere virtualization proved faster than native hardware (PDF Link) on the DayTrader performance benchmark with WebSphere. DayTrader, which is part of Apache Geronimo, the open-source Java Enterprise Edition (EE) 6 application server,  is a benchmark application that simulates an online stock trading system.

The HP benchmarking showed that with the right configuration of CPU cores, a virtualized environment exceeded the performance of physical environment in 2 cores and 4 cores configurations by about 4-percent and 6-percent respectively. In other configurations, the  virtual performance, with 1 core, 6 cores, and 8 cores proved to be, respectively, 5-percent, 5-percent and 10-percent slower.

In short, while virtualization can speed processing up, it doesn't just magically make things better. Without the right architecture and tuning, virtualization will not deliver performance benefits.

In a more recent study, albeit one by VMware, the company found that vSphere 5.1 on a 32-system Linux cluster running the open-source big data program Hadoop on a single virtual machine (VM) per server showed  performance that was close to native performance. Close, but no cigar.

However, by partitioning each host into two or four virtual machines, they were able to get significantly better performance. With two VMs, VMware found that the overall benchmark results with an 8 Terabyte dataset was almost as fast with native hardware,and with 4 VMs, the virtualized approach was actually 2-percent faster (PDF Link).

That may not sound like much, but when you're working with Big Data, that's a significant speed increase. Better still, it may also mean that you won't need to pay for as many physical servers to achieve the best possible results.

What all this means for you and your enterprise is that rather than just assuming that your HPC application needs can best be served by native hardware, you need to evaluate other, virtualization-based solutions to find the best match of performance, cost, and technology.

Related Stories:

Topics: Virtualization, Big Data, Linux, Open Source, Servers, VMware

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • please rush out and sell companies on this concept

    I will then have guaranteed employment for the foreseeable future fixing all the implementations that don't measure up to expectations. Hurrah!
  • Found this to be true

    ..with both VMware and Hyper-V. Of course, mine is a "seat of the pants" analysis.
    • it really depends on the workload and original hardware

      Virtualizing and old server or desktop >3yrs on a new platform will probably be faster if... but if your comparing apples to apples hardware vs virtualized on same then it will probably not be faster. Corner cases as described in this article excepting. Many other factors come into play... nature of the app(s), location of data and or services to be accessed, proximity of user(s) to virtualized instance, network latency & bandwidth to name a few. The permutations of performance impacting scenarios is almost limitless and it only takes one to spoil the user experience.
      • Windows is slow...

        ... terrible slow after one have used the operations system couple of years. It's one the the many reasons why i moved to Linux.
  • Great!

    I'll start running MC instead of Photoshop immediately!
  • and the reasons?

    Based on my past experience many years ago with HPC, there are usually two reasons for this "superscaling" - one is that it ends up caching better and the second is that with virtualisation you can end up with the virtualised communications running more efficiently than the physical communications.

    For the caching, a recent research project I have been managing has shown the optimal cache sizes for cloud applications, and current CPUs don't have the best balance between CPU and cache for optimised use of silicon.
    • The major reason depends on how the CPUs are virtualized...

      If each VM has one CPU, then using multiple VMs allows for scheduling optimization where two VMs are both busy- always guaranteeing no idle time.

      Communications optimization happens since they are both on the same hardware platform, so data transfer can be done with zero copy - the data page on one system is just unmapped from one, and mapped into the other.
  • Many opportunities for performance gains from virtualization

    When you have servers that talk to each other a lot (are network I/O bound, iow) then putting them on the same host will very often increase performance (it will always improve the network performance of that one channel - the only question is whether it triggers a different bottleneck that has a more punitive effect).

    Other scenarios include lots of edge cases where e.g. the ESXi I/O scheduler is more efficient/globally optimized than the local OS one (e.g., in Linux, setting the OS I/O scheduler to "noop" can often increase filesystem access times to network-mounted resources); also, distributed virtual switches can sometimes interoperate between hosts faster than the physical switching infrastructure.

    Then, if you allow dynamic resource scheduling full reign to e.g. move VMs when patterns of resource usage indicate an opportunity for performance gains, you can (sometimes) see real gains, because the system becomes "self-tuning" in a way that a non-virtualized system cannot be.
  • CPU yes

    If the task on hand is CPU dependent then virtualization is typically on par with hardware. In most cases disk dependent applications show a significant drop in performance, this of course is dependent on the disk configuration of the supporting virtualization technology. If possible it's best to resolve slow disk by providing a subsystem that delivers the desired IO. Once you go down the path of giving the VM dedicated resources you have in effect lost he purpose of the VM.
    • Not necessarily.

      Using multiple nodes (physical systems) that both have parallel, multiplexed fibre channel access to disks allows "dedicated" but still virtualized. If something happens, the VM can be moved and everything just picked up where it left off. Also works with infiniband.
  • "the right configuration of CPU cores"

    Ah, the hidden truth -- it's not a one-to-one comparison on the same machine. You have to specially configure the virtualization software on a special machine, and then somehow "normalize" the numbers. Perfectly good methodology....
  • If It's Faster Under One Layer Of Virtualization ...

    ... did anybody try two? That is, running the hypervisor itself in a virtual machine, under a hypervisor? If one layer of virtualization can add x% of performance, wouldn't two layers add 2x%?

    Not to mention ... THREE layers ...
    • Virtualception .....