Performance and capacity requirements for Hyper-V

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

Topic Last Modified: 2016-11-14

This article provides information about the performance and capacity requirements for deploying Microsoft Office SharePoint Server 2007 in a Hyper-V virtual environment.

In this article:

-
Introduction

-
Recommendations for configuring and optimizing Hyper-V

-
Hyper-V test environment and testing strategy

-
Test scenarios, results and analysis

-
Recommendations for deploying SharePoint on Hyper-V

-
Additional resources

Acknowledgments

-
Enterprise Engineering Center (EEC): Mike VanderMeer (EEC), Kevin Engman

-
Tony Voellm, Tim Litton

Introduction

This article describes the tests that were conducted to compare the performance of Office SharePoint Server 2007 servers deployed as guests on a Hyper-V host against SharePoint servers deployed on physical computers and provides recommendations for deploying Office SharePoint on Hyper-V. Although the tests described in this article are SharePoint-specific, the performance evaluation methods and performance testing scenarios are useful for analyzing the performance of virtualized server applications in general. The test results and guidance will be of interest to both the IT Pro and Developer communities.

All the performance tests described in this guide were conducted at the Microsoft Enterprise Engineering Center. The Enterprise Engineering Center (EEC) is a state-of-the-art, datacenter laboratory at the main Microsoft campus in Redmond, Washington. The EEC can replicate nearly any production environment and is used by Microsoft product groups and customers. You can find out more about the EEC at https://www.microsoft.com/eec (https://go.microsoft.com/fwlink/?LinkId=132796&clcid=0x409).

Before you deploy and test SharePoint in a Hyper-V environment, it is recommended that you read the following articles in the BizTalk Server 2006 R2 Hyper-V Guide:

• Hyper-V Feature Overview (https://go.microsoft.com/fwlink/?LinkId=132797&clcid=0x409)

• Hyper-V Architecture (https://go.microsoft.com/fwlink/?LinkId=132799&clcid=0x409)

The BizTalk Server 2006 R2 Hyper-V Guide also contains a glossary that is available at Glossary (https://go.microsoft.com/fwlink/?LinkId=132801&clcid=0x409).

Recommendations for configuring and optimizing Hyper-V

The tests conducted at the Enterprise Engineering Center (EEC) indicated that the following optimizations were of importance for deployment of SharePoint in a Hyper-V environment:

• Configure the correct amount of memory for Hyper-V guests. During the testing, no change had a greater impact on performance than modifying the amount of RAM allocated to an individual Hyper-V image. Because memory configuration is hardware-specific, you need to test and optimize memory configuration for the hardware you use for Hyper-V.

  The initial goal of the testing was to make the Hyper-V image as similar as possible to the physical hardware image against which it was being compared. Based on that goal, the Hyper-V images were originally allocated 32 gigabytes (GB) of RAM, which was the same amount of RAM as was on the physical servers being tested. However, the initial test results showed that with that configuration, the Hyper-V images could sustain a load that was only about 70 percent of the load on the physical hardware. After investigating the Event Viewer on the Hyper-V host machine in the Windows Server 2008  Custom Views, Server Roles, Hyper-V Events, it was discovered that the RAM for the Hyper-V images was being spread across multiple non-uniform memory access NUMA nodes. This information confirmed that performance declined when memory was allocated across nodes. After trying different configurations it was determined that for the hardware being used, 8 GB of RAM was the maximum that could be allocated to a Hyper-V image without crossing NUMA nodes.

  NUMA nodes

  In most cases you can determine your NUMA node boundaries by dividing the amount of physical RAM by the number of logical processors (cores). It is recommended that you read the following articles:

  • Hyper-V Performance Counters – Part five of many – "Hyper-V VM Vid Numa Node" (https://go.microsoft.com/fwlink/?LinkID=132805&clcid=0x409)

  • Looking for that last ounce of performance? Then try affinitizing your virtual machines (VM) to a NUMA node (https://go.microsoft.com/fwlink/?LinkId=132829&clcid=0x409)

• Use Windows Server 2008 as the guest operating system. The guest operating system used on the Hyper-V images for the tests was Windows Server 2008. Windows Server 2008 is not only required to host Hyper-V; it also contains a series of enlightenments aimed at making it the best possible Hyper-V guest operating system. Enlightenments are enhancements to the operating system to help reduce the cost of certain operating system functions such as memory management. For more information about enlightenments, see Tony Voellm’s blog post, Hyper-V: Integration Components and Enlightenments (https://go.microsoft.com/fwlink/?LinkId=132837&clcid=0x409).

• Install and test integration components. The Hyper-V integration components were installed on all of the Hyper-V images used for testing. Integration components (ICs) are sets of drivers and services that help your VMs achieve a more consistent state and perform better by enabling the guest to use synthetic devices. Examples of ICs that come with Hyper-V are the VMBus (the transport for synthetic devices), time sync (used to keep VM clocks in sync with the root partition (also called the host)), video driver, network driver, and storage driver. For tips that you can use to verify that the ICs are installed and working correctly, see Hyper-V: How to make sure you are getting the best performance when doing performance comparisons (https://go.microsoft.com/fwlink/?LinkId=132838&clcid=0x409).

• Install the Hyper-V update for Windows Server 2008 (KB950050) on the host and guests. This update to the Hyper-V role provides improvements to security, stability, performance, user experience, forward compatibility of configurations, and the programming model. Install this download on the Hyper-V hosts and the Hyper-V guests if the guest operating system is Windows Server 2008. Installing this update on the guest ensures that you can take full advantage of all available enlightenments. For more information, see Description of the update for the release version of the Hyper-V technology for Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=132841&clcid=0x409).

• Use IPv4 as the network protocol for Hyper-V guests (Windows Server 2003 and Windows Server 2008 only). During the tests, better performance was observed when IPv4 was used exclusively. IPv6 was disabled on each network card for both the Hyper-V host and its guest VMs.

  Note

  This condition was resolved in Windows Server 2008 R2 by including IPv6 offloading in the virtual network stack.

• Do not use unnecessary host roles. Remove any unnecessary roles from the host server. For example, if your host is not serving Web pages, the Web server (IIS) role should not be installed.

• Optimize host CPU use. If you use multiple Hyper-V images on the same host, conduct tests to ensure that the physical processors are used efficiently. Depending on hardware and workloads, the ratio of virtual processors to physical processors can have a significant effect on the host CPU. For the SharePoint tests, the ratio of virtual processors to physical processors was 1:2. It is recommended that you use the Microsoft Assessment and Planning (MAP) toolkit (https://go.microsoft.com/fwlink/?LinkId=132840&clcid=0x409) to obtain an assessment of your computer's performance metrics. For more information about CPU topology, read Ben Armstrong's blog post, Processor topology inside of Hyper-V virtual machines (https://go.microsoft.com/fwlink/?LinkId=132839&clcid=0x409).

• Make the right disk choice. In a SharePoint implementation where the only roles on Hyper-V are front-end Web servers or Query servers, the disk performance is not as important as it would be if the image was hosting the Index role or a SQL Server database. If the image hosts the Index role, using a fixed-size virtual hard disk (VHD) for the image delivers acceptable performance. A fixed-size virtual disk typical provides better performance than a dynamically-sized disk. For more information, see Hyper-V and VHD Performance - Dynamic vs. Fixed (https://go.microsoft.com/fwlink/?LinkId=132842&clcid=0x409).

  You can also choose to add one or more drives and connect to it by means of a virtual SCSI controller. The only real limitation here is that you cannot use the SCSI controller to connect to the drive that contains the guest operating system, which must be installed on a drive that uses an IDE controller. If disk speed is a high priority, consider adding physical drives to the host computer. To the Hyper-V guest system, you can add a virtual hard drive and map it to an unused physical drive on the host. This configuration, called a pass-through disk, is likely to give you the best overall disk throughput.

  Note

  A pass-through disk still must be connected to either the IDE or SCSI controller, so the same limitations apply with respect to installing the guest operating system on a drive connected to the IDE controller.

• Do not use the Hyper-V snapshot feature on virtual servers that are connected to a SharePoint Products and Technologies server farm. The timer servers that SharePoint uses might become unsynchronized during the snapshot process, and once the snapshot is finished, errors or inconsistencies can arise.

Hyper-V test environment and testing strategy

The tests at the Enterprise Engineering Center were designed to evaluate, as minutely as possible, the performance impact of running SharePoint on Hyper-V images versus running SharePoint on a comparable physical hardware configuration. 

The following server roles were installed on Hyper-V guests:

• The front-end Web server

• The Query server

The following server roles were installed on physical servers:

• The front-end Web server

• The Query server

• The SharePoint configuration and content database. The Index server role was added to the database for some test configurations. However, no crawls or profile imports were scheduled because measuring the impact on the crawler role was not in scope of the tests.

Test hardware configurations

The following table describes the hardware that was used for the tests. Each server used in a SharePoint farm had 2 x 146-GB (10,000 RPM) SAS drives in a RAID-1 configuration.

Hardware used for tests

Test software configurations

The following software was used on the test systems:

• The 64-bit edition of the Windows Server 2008 Enterprise operation system was installed on physical servers and Hyper-V guests.

• The 64-bit version of Microsoft SQL Server 2005 SP2 was installed on physical servers.

• The 64-bit version of Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) with the Infrastructure Update was installed on physical servers and Hyper-V images.

Test plan

The test plan that was executed was based on a collection of 39 individual tests referred to collectively as the MicroBenchMark (MBM) test. These tests have been used throughout the lifespan of Office SharePoint Server 2007, starting when the product was in beta. The tests cover a number of different usage scenarios in the product, such as viewing home pages, sites, document libraries, and lists, downloading and uploading items, and editing list items. Each test has a 30-second warm-up period and then runs for two minutes. (These tests were previously conducted by using Microsoft Application Center Test (ACT), but were rewritten to use Visual Studio 2008 Team Test).

The tests were run in a single Active Directory forest and domain environment that had 50,000 user accounts. The SharePoint data consisted of a standard set of site collections, sites, lists and document libraries, as well as My Sites and profiles that are used with the MBM test. This data was maintained by using a standard SharePoint backup (approximately 15 GB in size), which was used to restore a test system to its original state each time a new scenario was tested. The tests were run for five scenarios described in the following section.

Test scenarios, results and analysis

The MBM tests were run against the following farm deployment scenarios to determine how a SharePoint farm performance in a virtual environment compared to performance when the farm was deployed on physical servers.

• A small farm installed on a single physical server.

• A small farm on a single Hyper-V image.

• A medium farm (two front-end Web servers, each with the query role) installed on a physical server.

• A medium farm (two front-end Web servers, each with the Query role) installed on Hyper-V images. Each Hyper-V image was installed on a separate physical host.

• A medium farm (two front-end Web servers, each with the Query role) installed on Hyper-V images. All the Hyper-V images were installed on the same host.

The first set of tests was run against the physical servers to establish a baseline set of data points.

Baseline results and adjustments

The primary performance counters on which the initial tests focused were requests per second (RPS) and page response time, or time to last byte (TTLB). A number of scoping tests were run to identify the optimal user load for the test runs. The goal was to drive server CPU use to as close to 100 percent as possible, without generating excessive ASP.NET Requests Queued or page response times. The final user load amount that was used was optimal because when higher user loads were tested, very little, if any, gain was observed in the total RPS for the test, but the average TTLB began to increase.

After initial discovery work was done around the performance metrics of the Hyper-V images, it was clear that it was not feasible to use a Hyper-V image with 32 gigabytes (GB) of RAM for comparison. The reason was the way in which memory is allocated when the host machine has multiple non-uniform memory access (NUMA) nodes. Allocating 32 GB of RAM to a Hyper-V image required memory to be paged across multiple NUMA nodes on the host. The high level of memory use resulted in lowered performance. For the hardware used in this test, it was determined that the best memory configuration for the Hyper-V image was 8 GB. Because memory configuration was substantially lower than the single physical server that was the original target of this testing, a fifth scenario was added to compare two Hyper-V images running on a single host machine. The data from that environment was compared to both a single physical server as well as a medium farm of physical servers. This fifth scenario was designed in order to test the use of more Hyper-V images with approximately the same amount of resources that a single physical server consumed.

Comparative analysis: Small farm on single server

For these tests, a small farm was installed on a physical server and on a Hyper-V image.

Farm configurations

The configurations for this set of tests are described in the following tables and illustrations.

Roles and servers for physical server

The following illustration shows the topology for the roles and servers described in the preceding table.

Roles and servers for Hyper-V image

The following illustration shows the topology for the roles and servers described in the preceding table.

Test results

The first comparison point for this scenario is the requests per second (RPS) throughput for a small farm on a physical server and a small farm on a Hyper-V image. The following graph shows the RPS throughput for both configurations.

The second comparison point is the page response time, or time to last byte (TTLB) for each configuration, which is shown in the following graph.

The results of this set of tests show that the difference was small between the throughput and page response time results on the Hyper-V image and the results on the physical machine. For the Hyper-V farm, the total average throughput per test was 93 percent of the throughput for the physical server farm. The average page response time was only .03 second slower on the Hyper-V image. Both tests showed similar CPU use and available memory on both the SharePoint and SQL Server servers. With proper attention to the Hyper-V configuration, there was no significant difference in the overall performance of the two farms.

Comparative analysis: Medium farm with images on separate hosts

For these tests, a medium farm consisting of two front-end Web servers (each with the Query role) was installed on two physical servers and on two Hyper-V images. These images were installed on separate physical hosts.

Farm configurations

The configurations for this set of tests are described in the following tables and illustrations.

Roles and servers for physical server

The following illustration shows the topology for the roles and servers described in the preceding table.

Roles and servers for Hyper-V image

The following illustration shows the topology for the roles and servers described in the preceding table.

Test results

The first comparison point for this scenario is the requests per second (RPS) throughput, which is shown in the following graph.

The second comparison point is the page response time, or time to last byte (TTLB), for each configuration, which is shown in the following graph.

The results of this set of tests shows a pattern that is similar to the tests run for the small farms. The difference in throughput between the medium farm on physical servers and on Hyper-V images 11.6 percent, as compared to 7.2 percent for the small farm environment. This difference is due to the fact that that there are two images in the medium farm test environment. However, this difference is not linear from the small single server farm, where the requests were processed more quickly in the medium farm than they were in the single server farm, as indicated by the TTLB results.

Comparative analysis: Medium farm with images on same host

For these tests, a medium server farm, consisting two front-end Web servers, each with a query role, was installed as two Hyper-V images on a single physical server.

As described earlier, the Hyper-V images were allocated only 8 GB of RAM, which in total was only half the amount of RAM used for a small farm on a single physical server. However, the host for the two images had eight cores, compared to four cores for the small farm server. In effect, this test environment represents a capacity level that is near the middle of the performance capacity range for a single physical server and two physical servers.

Farm configurations

The configurations for this set of tests are described in the following tables and illustrations.

Roles and servers for images on single physical server

The following illustration shows the topology for the roles and servers described in the preceding table.

Test results

The first comparison point for this scenario is the requests per second (RPS) throughput shown in the following graph, which shows the results for the following:

• A medium farm with two images on a single host.

• A medium farm with two images on separate hosts.

• A medium farm on a physical server.

• A small farm on a physical server.

The following graph shows the TTLB results for the same farms used for the RPS graph.

The results for this set of tests on the different farm configurations raises two key points that may affect the design of farms deployed in a Hyper-V environment:

First, performance dropped slightly when two Hyper-V images were run on the same host rather than one image run on a single host. Two or more images are obviously the preferred implementation. Fortunately, the difference in throughput between the two environments was not great; throughput on a single host was 5 percent greater than on the same host. Compared to the medium physical farm, the throughput for the farm with dual Hyper-V images on a single host was 16 percent less, but it was also using one less physical machine so the results are actually more favorable that they appear to be.

Second, when the dual Hyper-V images on a single physical host was compared to a small farm on a single physical server, the throughput was 70 percent greater on the Hyper-V farm.

Recommendations for deploying SharePoint on Hyper-V

The different configuration options and resulting metrics underscore the need to evaluate all of the different options for configuration and deployment of SharePoint in a Hyper-V environment.

• There are important configuration options, such as memory, that will vary depending on the hardware that is used to host the Hyper-V images.

• There are a number of different topologies in which you can deploy a SharePoint farm on Hyper-V images. However, not all SharePoint roles are good candidates for running on Hyper-V. Once again, this depends on several factors, such as the Hyper-V host, as well as the capacity and performance requirements of your SharePoint farm.

In the most common scenario, using Hyper-V to run SharePoint servers in the front-end Web server with a query role is quite feasible — with a relatively small drop in throughput compared to the same roles installed on physical hardware. Depending on the host hardware, you may be able to further mitigate the difference in throughput by allocating more resources to the Hyper-V image (such as CPU, RAM and/or disk) than if you ran SharePoint on a similar physical server. Conduct extensive testing to ensure that the host machine is not over committing resources for the number of active Hyper-V images it is hosting.

Additional resources

The following tables provide important information about resources for Hyper-V, SharePoint Products and Technologies, and Microsoft SQL Server 2008.

Planning and deployment: Hyper-V

Performance: Windows, Hyper-V, SharePoint, and SQL Server 2008

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Office SharePoint Server 2007, part 2

See the full list of available books at Downloadable content for Office SharePoint Server 2007.

See Also

Concepts

Using SharePoint Products and Technologies in a Hyper-V virtual environment