Not too long ago, during the early days of client/server computing when application performance was so dependent on the network, we used to talk about whether an application was a good network citizen. If too much code ran on one side of the network or the other, chances are there would be an imbalance that would put too much pressure on the network. Applications that didn’t take that into account were referred to as bad network citizens.
With virtualization today, we hear a lot of poor application performance. What nobody is really 100 percent sure about yet is whether this is because of the I/O overhead generated by the virtual machines, or are the applications themselves just bad virtualization citizens.
Barry Zane, CTO of ParAccel, a provider of a massively parallel processing database, believes that poor virtual machine performance has a lot more to do with the way the application is built than it does with the virtual machines themselves. To back up that perspective, ParAccel today announced that it has achieved the fastest 1 TB TPC benchmark ever running is massively parallel database on top of VMware vSphere 4. That new benchmark record, the company said, attains database load times that are 8.7 times faster than the previous record holder using 37 percent fewer servers. Specifically, an 80-node cluster of ParAccel’s PADB version 2.5 consolidated on 40 DL380 servers from Hewlett-Packard running VMware vSphere 4 achieved 1,316,882 Composite Queries per Hour (QphH) at 1,000 GB, a price/performance of U.S. $.70/QphH.
Now the value of a benchmark is in the eye of the beholder. But Zane notes that his company’s database runs faster on top of virtual machine software that it does on some physical servers running some forms of Linux. He attributes that to the fact that VMware, for example, does a much better job managing I/O throughput than some of the work that has gone into Linux.
Whatever the reason, Zane says that when it comes to virtualization, the real name of the game to is avoid swapping memory. Virtual machines are obviously hungry for memory, but if properly managed they don’t present a performance issue. The key phrase there is “properly managed,” because what virtual machines will do is expose a poorly designed application pretty quickly.
