Microsoft SharePoint 2010 on HP ProLiant DL380p Gen8 servers

Technical white paper Microsoft SharePoint 2010 on HP ProLiant DL380p Gen8 servers Performance report Table of contents Executive summary... 2 Introduction... 2 Test topology... 2 Test methodology... 3 HP LoadRunner... 3 Test results... 5 Response times... 5 WFE CPU performance... 7 Back-end CPU performance... 8 Network consumption... 9 Test analysis summary... 9 Recommendation... 10 Appendix A... 10 LoadRunner... 10 LoadRunner Microsoft Internet Information Services (IIS)... 10 LoadRunner SQL Server... 11 WFE Performance Monitor... 11 SQL Server Performance Monitor... 12 For more information... 13

Executive summary As customers increasingly adopt Microsoft SharePoint 2010 to meet the collaborative needs of their businesses, HP continues to provide guidance on the successful infrastructure sizing and deployment of these solutions. This white paper explores the performance characteristics of HP ProLiant DL380p Gen8 servers in combination with HP StoreVirtual 4500 and the HP 2910-48G al Switch as they relate to a typical collaboration deployment with SharePoint 2010 and Microsoft SQL Server 2012. You have many choices when it comes to the underlying hardware for solutions, which is why HP strives to be the vendor of choice by constantly testing and understanding the needs of these solutions, and helping you deploy them correctly the first time. Target audience: Individuals or groups seeking guidance on the appropriate sizing and deployment of SharePoint 2010 on the latest generation of HP ProLiant servers, HP networking solutions, and HP Storage. This white paper describes testing performed in October 2012. Introduction SharePoint 2010 is one of the most prolific collaboration platforms available today, allowing people to work together in ways that best suit your business needs. However, this platform can be difficult to correctly size and deploy; as a result, HP offers guidance based on actual test results, allowing you to better understand the requirements of a SharePoint 2010 solution and the impact it may have on your existing infrastructure. The performance testing outlined in this white paper was designed to replicate typical workloads you might encounter when deploying SharePoint 2010 on HP products such as ProLiant Gen8 servers, HP Storage, and HP networking solutions. However, because SharePoint 2010 can be deployed and configured in many different ways, your results may vary depending on actual workloads and differences in configuration. The configuration described in this paper should not be considered to be the only configuration recommended by HP for SharePoint 2010 deployments; rather, it is just one particular solution. Important While this testing can provide a benchmark to be used for comparing hardware and/or software products, it is not intended to serve as a sizing guideline. In the real world, server performance is highly dependent upon application design and workload profiling. As with any laboratory testing, the performance metrics quoted in this paper are idealized. In a production environment, these metrics may be impacted by a variety of factors. As a matter of best practice for all deployments, HP recommends implementing a proof-of-concept using a test environment that matches as closely as possible the planned production environment. In this way, appropriate performance and scalability characterizations can be obtained. For help with a proof-of-concept, contact an HP Services representative or your HP partner. Test topology The benchmark testing described in this paper explores the performance characteristics of the DL380p Gen8 server in combination with HP StoreVirtual 4500 and an HP 2910-48G al Switch when used in a typical collaboration deployment with SharePoint 2010 and SQL Server 2012. Two DL380p Gen8 servers were used, each configured with two Intel Xeon E5-2690 CPUs, 192 GB of RAM, and two local hard drives (HP 300GB 6G SAS 15K rpm small form factor (SFF) enterprise hard drives). SharePoint 2010 was installed on one server typically known as the web front end (WFE); SQL Server 2012 was installed on the second server. An HP StoreVirtual 4500 was connected to the SQL Server machine to provide storage for the content database. 2

All systems were connected via 1 Gb network links provided by an HP 2910-48G al switch, isolating the following traffic on to separate physical connections: Clients WFE WFE SQL Server SQL Server HP StoreVirtual 4500 This type of isolation, which is considered by HP to be a best practice for a SharePoint 2010 deployment, also allows you to accurately gauge the level of traffic between tiers. Figure 1 illustrates the tested configuration. Figure 1. Architectural diagram of solution HP 2910-48G al Switch HP ProLiant DL380p Gen8 Server HP ProLiant DL380p Gen8 Server Web Front End SQL Server 2012 HP StoreVirtual 4500 Test methodology In order to properly test this or any other SharePoint 2010 deployment, you should emulate actual users that are performing typical tasks in the way a real user would interact with SharePoint 2010 sites. This involves the following activities: Logging on to and manipulating a SharePoint 2010 site Uploading and downloading content Making changes to site data Performing tasks that change the site In order to achieve this type of workload, HP LoadRunner, an industry standard for application performance testing, was used. HP LoadRunner HP LoadRunner can emulate hundreds or thousands of concurrent users and apply workloads to almost any client platform or environment. By applying consistent, measurable, and repeatable loads, LoadRunner stresses an application from end to end, providing test results that can be used to identify scalability issues that might affect real users in a production environment. In this particular testing, HP engineers used the web protocol within LoadRunner s Virtual User Generator (VuGen) to record several different types of activities. The resulting scripts were then combined, modified, and parameterized to apply to a multiple-user SharePoint 2010 environment. 3

The workload created known as the SharePoint 2010 enterprise collaborative workload was representative of a typical collaborative environment and was designed to test against a range of web applications, each stressing a different aspect of the SharePoint 2010 deployment. User decision points were incorporated throughout the testing. For example, the division between web applications was as follows: Document Center (DocCtr) 30% Team Sites (TeamSite) 20% Portal Site (Portal) 20% Mysite (MySite) 10% Search (Search) 20% Timing was also an important consideration. Each particular task, such as opening an item or navigation, resulted in a wait time of one to four seconds to emulate a user reading the content being rendered. Response times (excluding the emulated wait times) for each task were recorded and were used to judge the responsiveness of the deployment. Each web application is outlined below. Document Center Users logging on to a document center are expected to perform tasks that are focused on document collaboration and management. Thus, this workload emulates users checking out, changing and uploading, and checking in a document. Versioning is turned on, and limited to three major versions. With every check in, a new version is created and stored within the content database. Users in the document center are also expected to manage tasks in a task list. They read, create, and delete these tasks, also causing change within the content database for this web application. User decision points are driven randomly, with the user working with documents 75% of the time and working with tasks 25%. Team sites The initial deployment of the Team Sites web application creates 25 different team sites. A user logging on to the Team Sites host site randomly chooses a team site to work in. The workload includes the following areas: Discussion threads (50%) The user navigates to a pre-populated thread, reads the thread, and then, 30% of the time, creates a response Calendar (20%) The user either reads existing calendar entries (50% of the time) or creates new entries (50% of the time) Document management (30%) The user uploads a Microsoft Office Excel file to the document library of the particular team site Portal Site The Portal Site web application is designed to emulate users hitting a corporate portal page that contains a lot of static content. This workload includes the following areas: Events (40%) The user navigates to a specific list and reads a pre-populated entry Announcements (40%) The user navigates to a specific list and reads a pre-populated entry Survey (20%) The user navigates to the survey application and randomly chooses an answer to a survey Mysite Introduced as the foundation for corporate social media in SharePoint 2010, the Mysite feature allows users to have their own personal location on the SharePoint site. Here they can store files and develop a taxonomy based on their expertise (as specified within metadata contained in their files). For this web application, users log on to their own mysite and upload a document containing pre-generated metadata. Search Since a key component of any SharePoint 2010 deployment is the ability to find relevant information, the following search functionality is important: Content indexes Created by crawling the site s content Taxonomy Created from user information and metadata contained within the site s content 4

During the setup phase of the testing, a rich, deep taxonomy was created by uploading over 5 GB of documents that were pre-populated with metadata and assigned to the existing user base. Thus, after logging on to the Search web application, the user can perform a search based on the known list of metadata tags that were used to create the documents. The resulting search contains documents matching the metadata tags along with the users associated with the particular documents. 25% of searches result in a file being directly downloaded from the document center. Test results Tests results are provided for the following: Response times WFE CPU performance Back-end CPU performance Network consumption For more information on the performance counters used, refer to Appendix A. Response times 250 concurrent users were utilized to characterize the performance of the HP products used in this SharePoint 2010 solution. Note In a SharePoint environment, you can think of the number of concurrent active users as being a small percentage of the entire user base. For a collaboration workload, this percentage is widely accepted to be 10%; thus, if you have 250 concurrent active users as in the test environment, the user base for the solution would be around 2,500. Of course, this percentage can vary widely in real-world environments based on the type of work that is actually being performed. Table 1 summarizes transaction times for activities within the various web applications. These times were extracted from a time span of 60 minutes, starting one hour after the beginning of user ramp-up and ending before user ramp down began. This time span was steady-state, with all users logged on and working. Table 1. Transaction response times in milliseconds Transaction name Minimum Average Maximum Total transactions DocCtr - Checkin Document 0.186 0.800 6.042 11,048 DocCtr - Checkout Document 0.115 0.506 5.074 11,048 DocCtr - Close Task 0.001 0.003 0.027 1,664 DocCtr - Create a task 0.191 0.808 11.396 1,670 DocCtr - Delete a task 0.073 0.214 0.937 1,670 DocCtr - Download Document 0.062 0.477 2.933 11,048 DocCtr - Nav to Document Center 0.055 0.151 6.393 11,160 DocCtr - Nav to Document Site 0.099 0.579 3.208 14,496 DocCtr - Nav to Folder 0.064 0.172 2.885 11,156 DocCtr - Nav to Tasks 0.047 0.110 0.699 3,335 DocCtr - Open Task 0.037 0.245 1.583 1,664 DocCtr - Upload Document 0.684 3.221 15.614 8,455 5

Transaction name Minimum Average Maximum Total transactions MySite - Nav to My Content 0.086 0.151 3.124 7,283 MySite - Nav to Mysite Site 0.053 0.605 6.071 7,287 MySite - File Upload 0.810 7.214 18.386 7,280 Portal - Close Announcement 0.001 0.003 0.036 5,875 Portal - Close Event 0.001 0.003 0.028 5,733 Portal - Nav to Announcements 0.035 0.065 3.094 5,901 Portal - Nav to Events 0.042 0.067 3.068 5,714 Portal - Nav to Portal Site 0.056 0.652 3.450 14,741 Portal - Nav to Survey 0.036 0.064 3.052 3,126 Portal - Open Announcement 0.050 0.221 1.291 5,887 Portal - Open Event 0.054 0.211 1.295 5,721 Portal - Respond to Survey 0.109 0.289 2.308 3,126 Search - Download Document 0.027 0.524 9.950 3,372 Search - Nav to Search Site 0.062 0.462 2.307 14,634 Search Searching 0.170 0.273 3.213 14,277 TeamSite - Close Entry 0.001 0.004 1.381 4,875 TeamSite - Create Calendar Entry 0.163 0.704 6.181 1,688 TeamSite - Delete Calendar Entry 0.080 0.213 2.290 1,658 TeamSite - Nav to Calendar 0.044 0.281 4.496 8,269 TeamSite - Nav to Shared Documents 0.036 0.080 2.675 4,476 TeamSite - Nav to Team Discussion 0.039 0.088 2.355 10,887 TeamSite - Nav to Teams Site 0.094 0.481 2.716 21,966 TeamSite - Nav to Teamsite 0.059 0.260 3.045 21,949 TeamSite - Open Discussion 0.085 0.234 3.031 10,884 TeamSite - Open Entry 0.063 0.355 4.062 4,879 TeamSite - Reply to Discussion 0.229 0.716 5.648 3,544 TeamSite - Upload Document 0.152 0.348 3.103 4,479 With the exception of file uploads to the document center and mysites, average response times were all below one second, indicating that the solution was performing excellently, with no sign of a bottleneck. The wide variation in file upload and download times can be attributed to differences in document size and on random decisions concerning which files to transfer. 6

WFE CPU performance To understand how each of the solution tiers was performing, HP analyzed records from a broad range of performance counters. Figure 2 shows CPU performance in the DL380p Gen8 server used for the WFE tier. Figure 2. WFE CPU consumption The WFE consumed an average of 28.5% of available CPU resources, with peaks up to 47%. At the same time, SharePoint 2010 was committing 18 GB of RAM and requiring an average of 29.5 IOPS. To put this in perspective, clients were recording 1,500 hits per second while ASP.net counters were reporting 1,000 requests per second. On average, 82 total transactions per second were being completed. 7

Back-end CPU performance Figure 3 shows CPU performance in the DL380p Gen8 server used for the SQL Server solution tier. Figure 3. SQL Server CPU consumption On average, SQL Server consumed a mere 3.9% of available CPU resources, with peaks up to 8.5%. SQL Server cached all of the content databases and was committing 44 GB of RAM. The average IOPS value was 1,037, with peaks to 2,580. The majority of I/Os were write, which was not surprising given that SQL Server had cached all the content databases. SQL Server maintained an average write throughput of 50 MB/s, with an average disk queue length of 42. 8

Network consumption Figure 4 illustrates network consumption at the HP 2910-48G al switch. Figure 4. Network consumption for the entire solution The red line denotes client WFE traffic, which averaged 470 Mb/s, with peaks to 648 Mb/s. The blue line denotes WFE SQL Server traffic, which averaged of 410 Mb/s, with peaks to 734 Mb/s. Given that each of these connections is support by a 1 Gb/s link, network consumption is a potential area for concern. Test analysis summary Deploying SharePoint 2010 can be a complex and sometimes daunting task. Failure to understand how SharePoint 2010 performs, the requirements made on the underlying hardware, and the impact the solution may have on the existing infrastructure can result in a poor implementation with long-term performance implications. The testing described in this white paper can be used to identify the following key focus areas for a SharePoint 2010 deployment: Networking SharePoint 2010 relies heavily on networking connectivity between clients and the multiple tiers of the solution and, without careful planning, could quickly consume these networking links. Thus, when deploying SharePoint 2010, you should seriously consider its impact on your current networking infrastructure and, if appropriate, implement higher speed connections to the data center. HP offers a wide selection of networking equipment designed to support the 10 Gb/s links that are highly recommended for larger SharePoint deployments. SQL Server tier Performance on the SQL Server tier in a collaboration deployment for SharePoint is more dependent on memory size and I/O throughput than on CPU resources. In this particular solution, for example, the SQL Server tier consumed large amounts of RAM and IOPS while barely exercising the CPU capabilities of the DL380p Gen8 server. Given that the new pricing model for SQL Server 2012 is dependent on the number of available cores, a single-socket, six-core version of this server might be more appropriate for an actual deployment. Additionally, given the IOPS load at this level, you might consider larger, more robust HP Storage when taking into account growth and variations in workload. WFE The tested workload consumed less than half of the CPU resources available in the WFE tier, leaving more than 50% of the server s computational abilities idle. To increase resource utilization, you could downgrade the server to a single-socket solution, which would also reduce the up-front cost of the solution. 9

High availability (HA) Although it was not built into the deployment described in this white paper, HA should always be a primary concern in mission-critical environments. For SharePoint 2010, one method recommended for achieving HA is to double the server hardware, create a Windows failover cluster for SQL Server, and use Windows load balancing for WFE roles. Disaster Recovery (DR) Hand in hand with HA, you should also consider how to get your solution back up and running following a disaster. While there are many options for achieving DR in a SharePoint 2010 deployment, your particular choice will depend on a balance between cost and the amount of downtime you are willing to bear. HP Services can provide guidance on these options and provide recommendations tailored to meet your individual needs. Virtualization Given the nature of the test results described in this white paper, you may wish to explore the possibility of virtualizing this environment to make more efficient use of your hardware resources. Planned white papers from HP will cover the virtualization of this workload so as to provide a more cost-effective solution that better utilizes your investment in HP ProLiant servers. Recommendation Customers considering deploying SharePoint 2010 within an existing infrastructure should not only analyze the hardware requirements of the deployment but should also consider how a SharePoint solution might affect the existing infrastructure. SharePoint 2010 can consume large amounts of network capacity, potentially resulting in a bottleneck that can affect not only the SharePoint deployment but all other solutions relying on network throughput. Additionally, in the case of SharePoint, when the expected network consumption begins to increase, you may need to investigate the amount of data sprawl and the storage needed to contain it. SharePoint deployments tend to grow in size and scope over time as the user community finds new and different ways to incorporate it into their daily work routines. As a result, you should not only focus on the solution being deployed but also on how this solution may evolve over time so that you can plan for growth. HP provides a wide range of products and services to help you get the most from your SharePoint investment, including the HP Sizer for Microsoft SharePoint 2010 a free tool from HP that allows you to accurately size the hardware needed for your SharePoint 2010 deployment. Appendix A The following is a list of counters and items recorded by HP LoadRunner during the testing phase for this white paper. LoadRunner Hits per Second Throughput Transaction Summary Average Transaction Response time LoadRunner Microsoft Internet Information Services (IIS) # Bytes in all Heaps (.NET CLR Memory _Global_):wfe2012 # of current logical Threads (.NET CLR LocksAndThreads _Global_):wfe2012 # of current physical Threads (.NET CLR LocksAndThreads _Global_):wfe2012 # of current recognized threads (.NET CLR LocksAndThreads _Global_):wfe2012 # of Exceps Thrown / sec (.NET CLR Exceptions _Global_):wfe2012 # of Pinned Objects (.NET CLR Memory _Global_):wfe2012 # of total recognized threads (.NET CLR LocksAndThreads _Global_):wfe2012 % Time in GC (.NET CLR Memory _Global_):wfe2012 Bytes in Loader Heap (.NET CLR Loading _Global_):wfe2012 Bytes Received/sec (Web Service _Total):wfe2012 Bytes Sent/sec (Web Service _Total):wfe2012 Contention Rate / sec (.NET CLR LocksAndThreads _Global_):wfe2012 Current Connections (Web Service _Total):wfe2012 Current File Cache Memory Usage (Web Service Cache):wfe2012 Current Files Cached (Web Service Cache):wfe2012 Current ISAPI Extension Requests (Web Service _Total):wfe2012 Current Metadata Cached (Web Service Cache):wfe2012 Current NonAnonymous Users (Web Service _Total):wfe2012 Current URIs Cached (Web Service Cache):wfe2012 10

Get Requests/sec (Web Service _Total):wfe2012 ISAPI Extension Requests/sec (Web Service _Total):wfe2012 Kernel URI Cache Hits/sec (Web Service Cache):wfe2012 Large Object Heap Size (.NET CLR Memory _Global_):wfe2012 Locked Errors/sec (Web Service _Total):wfe2012 Maximum Connections (Web Service _Total):wfe2012 Not Found Errors/sec (Web Service _Total):wfe2012 Post Requests/sec (Web Service _Total):wfe2012 Throw To Catch Depth / sec (.NET CLR Exceptions _Global_):wfe2012 LoadRunner SQL Server Average Wait Time (ms) (SQLServer Locks _Total):sbe2012 Batch Requests/sec (SQLServer SQL Statistics):sbe2012 Buffer cache hit ratio (SQLServer Buffer Manager):sbe2012 Cache Hit Ratio (SQLServer Plan Cache _Total):sbe2012 Checkpoint pages/sec (SQLServer Buffer Manager):sbe2012 Full Scans/sec (SQLServer Access Methods):sbe2012 Lazy Writes/sec (SQLServer Buffer Manager):sbe2012 Memory Grants Pending (SQLServer Memory Manager):sbe2012 Number of Deadlocks/sec (SQLServer Locks _Total):sbe2012 Page Life Expectancy (SQLServer Buffer Manager):sbe2012 Page Splits/sec (SQLServer Access Methods):sbe2012 SQL Compilations/sec (SQLServer SQL Statistics):sbe2012 SQL Re-Compilations/sec (SQLServer SQL Statistics):sbe2012 Target Pages (SQLServer Buffer Manager):sbe2012 Target Server Memory (KB) (SQLServer Memory Manager):sbe2012 Temp Tables Creation Rate (SQLServer General Statistics):sbe2012 Total Server Memory (KB) (SQLServer Memory Manager):sbe2012 WFE Performance Monitor % Disk Time (PhysicalDisk _Total):wfe2012 % Idle Time (PhysicalDisk _Total):wfe2012 % Interrupt Time (Processor _Total):wfe2012 % Privileged Time (Processor _Total):wfe2012 % Processor Time (Processor _Total):wfe2012 Available MBytes (Memory):wfe2012 Avg. Disk Bytes/Transfer (PhysicalDisk _Total):wfe2012 Avg. Disk Queue Length (PhysicalDisk _Total):wfe2012 Bytes Total/sec (Server):wfe2012 Cache Bytes (Memory):wfe2012 Committed Bytes (Memory):wfe2012 Context Switches/sec (System):wfe2012 Transfers/sec (PhysicalDisk _Total):wfe2012 File Data Operations/sec (System):wfe2012 Free Megabytes (LogicalDisk _Total):wfe2012 Interrupts/sec (Processor _Total):wfe2012 Page Faults/sec (Memory):wfe2012 Page Reads/sec (Memory):wfe2012 Pages/sec (Memory):wfe2012 Pool Nonpaged Bytes (Memory):wfe2012 Pool Nonpaged Bytes (Server):wfe2012 Pool Paged Bytes (Memory):wfe2012 Pool Paged Bytes (Server):wfe2012 Pool Paged Failures (Server):wfe2012 Private Bytes (Process _Total):wfe2012 Processor Queue Length (System):wfe2012 Requests/Sec (ASP.NET Applications Total ):wfe2012 Split IO/Sec (PhysicalDisk _Total):wfe2012 System Cache Resident Bytes (Memory):wfe2012 11

Threads (Objects):wfe2012 Working Set (Process _Total):wfe2012 SQL Server Performance Monitor % Disk Time (PhysicalDisk _Total):sbe2012 % Idle Time (PhysicalDisk _Total):sbe2012 % Interrupt Time (Processor _Total):sbe2012 % Privileged Time (Processor _Total):sbe2012 % Processor Time (Processor _Total):sbe2012 Available MBytes (Memory):sbe2012 Avg. Disk Bytes/Transfer (PhysicalDisk _Total):sbe2012 Avg. Disk Queue Length (PhysicalDisk _Total):sbe2012 Bytes Total/sec (Server):sbe2012 Cache Bytes (Memory):sbe2012 Committed Bytes (Memory):sbe2012 Context Switches/sec (System):sbe2012 Disk Transfers/sec (PhysicalDisk _Total):sbe2012 File Data Operations/sec (System):sbe2012 Free Megabytes (LogicalDisk _Total):sbe2012 Interrupts/sec (Processor _Total):sbe2012 Page Faults/sec (Memory):sbe2012 Page Reads/sec (Memory):sbe2012 Pages/sec (Memory):sbe2012 Pool Nonpaged Bytes (Memory):sbe2012 Pool Nonpaged Bytes (Server):sbe2012 Pool Paged Bytes (Memory):sbe2012 Pool Paged Bytes (Server):sbe2012 Pool Paged Failures (Server):sbe2012 Private Bytes (Process _Total):sbe2012 Processor Queue Length (System):sbe2012 Split IO/Sec (PhysicalDisk _Total):sbe2012 System Cache Resident Bytes (Memory):sbe2012 Threads (Objects):sbe2012 Working Set (Process _Total):sbe2012 12

For more information HP Collaboration Solutions for Microsoft SharePoint, http://h71028.www7.hp.com/enterprise/cache/3960-0-0-0-121.html HP ProLiant DL380p Gen8 Server, hp.com/servers/dl380 HP StoreVirtual Storage, hp.com/go/storevirtual HP Networking, hp.com/go/networking HP LoadRunner, hp.com/go/loadrunner HP Services, hp.com/go/services HP Sizer for Microsoft SharePoint, hp.com/solutions/microsoft/sharepoint/sizer Microsoft SharePoint 2010, http://sharepoint.microsoft.com Microsoft SQL Server 2012, microsoft.com/sqlserver/en/us/default.aspx To help us improve our documents, please provide feedback at hp.com/solutions/feedback. Sign up for updates hp.com/go/getupdated Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. Intel and Xeon are trademarks of Intel Corporation in the U.S. and other countries. 4AA4-7504ENW, June 2013