Microsoft SQL Server runs at roughly 80% of native on VI3 in most benchmarked environments. In production environments, and under loads that model those conditions, SQL Server runs at 90-95% of native on ESX 3.5. I can say this with confidence despite a large amount of the industry's skepticism because I've spent so much time on SQL Server in the past half year. I'd like to share some of my research on the subject and observations with you.

Two weeks ago my colleague Chethan Kumar and I presented on SQL Server in Cannes, France for VMworld Europe 2009. This presentation was the culmination of six months of investigation that was started at VMworld 2008 in Las Vegas. At that event I heard so many concerns about SQL Server performance that I was resolved to identify the problems. I talked with every customer I could find that claimed that SQL ran at anything less than 70% of native. So many of these contacts claimed that they had measured SQL at 25% of native or worse, that I knew that something was going wrong.

First, let me show you a slide that Chethan presented at the show in Cannes:



Chethan spent three months investigating SQL Server to find out how much he could improve virtual performance from the "out of the box" experience. As this figure details, the sum total of performance improvements was 15%. Here's another break-down of these results:



The only option that we found in ESX to improve virtual performance was static transmit coalescing, which is documented on page four of one of our SPECweb papers. Large pages and SQL's priority boost, which are best practices provided by Microsoft for SQL Server configuration, provide the largest gains in performance.

The key messages that we communicated to our audience were that a properly running SQL Server should run at 80% of native or better. In most production cases it can run at a performance indistinguishable from native speed. And if performance is lagging, there don't exist many changes that can be made to ESX that can yield and performance gains at all.

This begs the question: "If ESX can't be tuned to double SQL performance, what is causing these reports of terrible SQL Server throughput?" The great majority of the problems are coming from mis-configured storage. But a variety of other items such as poor hardware selection or use of the wrong virtualization software contribute to the confusion, as well. I've been documenting these issues in Best Practices for SQL Server on this community and will continue to update that document as more problems are discovered.

If you have a SQL Server running un-virtualized in your environment, I'd like you to try virtualizing it again. Follow our best practices document and pay close attention to your storage configuration during deployment. I feel confident that once you've setup your environment properly, you're going to like what you see.

For years now VMware has been providing products that enable a virtual desktop experience. Historically, this would occur in virtual desktops on our hosted products but in some cases virtualization of Citrix XenApp (formerly presentation server) could provide a large number of desktops off a single virtual machine. And more recently VMware View offers a means of hosting a large number of desktops on a single server where each is granted its own operating system instance. As the number of virtual desktops and alternatives for implementing virtual desktops has grown, the need for a benchmark that can compare the performance of these alternatives has arisen.

Desktop benchmarking is not new to the industry, as people have been using PCs for decades. But standards in virtual desktop benchmarking are non-existent. Some might argue that traditional tools, common to PCs for years, should be used. But there are several reasons why this is not true:

1. Pre-virtual desktop benchmarking is built to completely saturate all memory and CPU resources provided. Fully saturating CPU on a single multi-way VM, as an example, results in far fewer VMs per host than is common in VDI deployments. Fewer VMs means less work for the hypervisor's scheduler.
2. Existing desktop benchmarks are often throughput-based, as opposed to latency-based. Because existing tools want to differentiate between powerful processors and large amounts of memory, they're designed to pack more and longer instructions in each run than is common in virtual desktop deployments. Most desktop deployments won't run massive video renders but the response times of individual button clicks and window appearance is critical.
3. No existing benchmarks are aware of the peculiarities of VM-based timing. VDI benchmarks need to be aware of this by either using host timing or invoking and measuring operations from remote, non-virtual locations.

At VMworld 2008 VMware presented a VDI workload that had been constructed from a collaborative effort between all VDI teams within VMware with review and qualification by several of our partners. The first measurements on this workload came from Dell and EqualLogic and we quickly made details on its characteristics available via white paper. Key features of this workload include:

• A diverse set of applications (Word, PowerPoint, Excel, Acrobat, and Internet Explorer) common to business desktop deployments.
• Load generation modeled after the most common VDI deployments.
• Small (less than 500 ms) operation generation and measurement.
• Host-based measurement and an architecture to support remote command invocation in the next release.

As an attempt at the world's first VDI benchmark, we're very pleased with our efforts. We found that it met the unique requirements in measuring virtual desktops of all kinds. And since it was generated with large group of internal collaborators and multiple partners, it's an excellent beginning at what the industry needs to standardize this process.

But today we realize that its just a beginning. I want to encourage everyone to bring your comments to VMware via this blog or the performance forums on what you think the characteristics of a industry standard virtual desktop benchmark should be. We'll never make one benchmark that meets everyone's needs and I suspect that there are even some common needs that will require significant development resources. But I expect that with your guidance and assistance in refining this workload we'll accelerate the process of getting this benchmark in a shape that the industry can embrace

I'm going to be at EMC World 2008 from May 19 through May 23. I'll be presenting on VMware's VI3 architecture with respect to performance, tips and techniques for performance monitoring and analysis, and best practices for best performance. My session, titled "VMware ESX Server Performance Analysis", is offered on Monday at 4:30 and Tuesday at 11:30. I'll also be hosting birds-of-a-feather sessions on the same subject at 2:30 on Tuesday. Please drop by if you're at the conference!