Capacity Planning for Microsoft Office SharePoint Portal Server 2003

White Paper

Published: February 2004

Table of Contents
Introduction.....................................................................................................1 Who Should Read This White Paper?.................................................................2 What Are Recommendations Based On?............................................................2 Solution Requirements.....................................................................................2 Hardware Requirements..................................................................................3 Deployment Scenarios.....................................................................................3 Single-Server Deployment...............................................................................4 Small Farm.......................................................................................... ..........5 Medium Farm............................................................................................. ...6 . Large Farm.......................................................................................... ..........6 Shared Services........................................................................... ..................7 Scalability Recommendations..........................................................................8 Web Page Throughput........................................................................... ..........8 Search Throughput.............................................................................. ...........9 Index Throughput..........................................................................................9 High Availability...........................................................................................10 Storage........................................................................................ ...............10 Other Recommendations...............................................................................10 Common Operations.......................................................................................11 Authentication.......................................................................................... 11 .... Customizations............................................................................................ 11 .
Custom Web Parts........................................................................................................11 Event Handlers.............................................................................................................12 Modified Pages.............................................................................................................12

Search................................................................................ ........................12 Security....................................................................... ...............................12
Windows Security Groups for Large Sites.........................................................................12

Asynchronous Operations..............................................................................13 Audiences............................................................................................. ......13 . Backup................................................................................................... ....13 . Indexing................................................................................................... ..13 . Index Propagation........................................................................................14 Profile Import............................................................................................. .14 .
Capacity Planning for SharePoint Portal Server 2003 i

Restore.............................................................................. .........................14 Long-Running Operations..............................................................................15 Folder Renames........................................................................................... 15 . Other Long-Running Operations.....................................................................15 Infrastructure Operations..............................................................................15 Single Sign-on Operations.............................................................................15 Web Services......................................................................... ......................15 Planning for Growth.......................................................................................15 CPU Consumption............................................................................ .............16
Adding a New Front-End Server......................................................................................16 Adding a New Back–End SQL Server................................................................................17 Adding a New Indexer...................................................................................................17 Adding Content............................................................................................................17 Adding a Site...............................................................................................................17 Adding a Portal Site......................................................................................................18

Disk Consumption......................................................................................... 18
Adding a New User Profile..............................................................................................18 Adding Content............................................................................................................18 Adding a New Content Database.....................................................................................18 Adding New Sites..........................................................................................................18 Adding a Portal Site......................................................................................................18

Network Consumption...................................................................................19 Memory Consumption...................................................................................19
Adding an Alert............................................................................................................19 Adding Content or Sites.................................................................................................19 Adding a Portal Site......................................................................................................19 Using Shared Services...................................................................................................19

Table of Boundaries......................................................................................20 Summary.......................................................................................................21

Capacity Planning for SharePoint Portal Server 2003

ii

Capacity Planning for Microsoft Office SharePoint Portal Server 2003
White Paper
Kimmo Forss Microsoft Corporation

Published: February 2004
For the latest information, please see the SharePoint Portal Server site on Microsoft Office Online| http://go.microsoft.com/fwlink/?linkid=21567&clcid=0x409

Introduction
Microsoft® SharePoint™ Products and Technologies facilitate easy, connected collaboration throughout an organization. By using the combined collaboration features of Microsoft® Windows® SharePoint Services and the enterprise portal site capabilities of Microsoft® Office SharePoint™ Portal Server 2003, organizations can enable users to create and manage their own rich and easy-to-build SharePoint sites—and then enable the entire organization to organize, discover, and profit from these sites. To be effective, portal site deployments must respond to a challenging set of requirements, including ease of deployment and management, service availability and throughput, and organizational flexibility. These requirements typically evolve with time and vary greatly depending on the size and complexity of the organization. SharePoint Portal Server 2003 successfully addresses these challenges by: • Using Microsoft® Windows Server™ 2003 and Microsoft SQL Server™ 2000 for outstanding extensibility and performance • Supporting a multiple-server architecture for high availability, scalability, and flexibility • Supporting tight integration of multiple server farms to address organizational and security requirements With a well-trained staff and a large budget, it is possible to keep a Web site running at top performance. With more realistic budgets, however, you must balance hardware costs with site performance. Capacity planning is the process of matching a usage load on a Web site to the minimum server hardware required to support that load. The goal of capacity planning is to ensure that your solution can support transactional throughput targets with acceptable response times while reducing the cost of site ownership.
Capacity Planning for SharePoint Portal Server 2003 1

Accurate capacity planning estimates must consider numerous factors, including number of users, site-specific usage patterns, and server loads. However, this information is seldom known in advance, and few administrators have time to conduct a detailed analysis of these patterns. Therefore, the purpose of this white paper is to provide capacity planning guidelines for a SharePoint Portal Server 2003 installation. It describes the main issues you encounter and the decisions you must make when determining the optimal SharePoint Portal Server 2003 deployment for your organization. It also provides hardware configuration recommendations for server farm and single-server deployments.

Who Should Read This White Paper?
This white paper is intended for IT professionals who are planning a new SharePoint Portal Server 2003 deployment. For additional information about planning and deploying SharePoint Portal Server 2003 solutions, see the Microsoft Solution Accelerator for Intranets|http://go.microsoft.com/fwlink/?LinkId=21787

What Are Recommendations Based On?
The recommendations in this white paper are based on experiences from early deployments and intensive lab testing. The performance of SharePoint Portal Server 2003 has been evaluated on a variety of hardware configurations, including multiprocessor single servers and server farms. These tests were conducted on well-maintained, preconfigured, installed systems using the default functionality and Web Parts.

Solution Requirements
Determining storage needs—and the hardware solution—is a critical step in planning a SharePoint Portal Server 2003 deployment. Unfortunately, it is often difficult to establish clear, detailed performance and scalability requirements for portal site deployments, since it can be hard to predict the level or type of site use. To complicate matters, the level of use frequently grows and changes over time. Nevertheless, you can often use throughput measured as pages per second as a guideline for measuring performance. To learn more about determining the needed throughput, see Scalability Recommendations, later in this white paper. SharePoint Portal Server 2003 uses the services provided by Windows SharePoint Services. Because Windows SharePoint Services addresses the needs of individual teams with a general set of features, few strategic choices are required in deploying the functionality needed for Windows SharePoint Services. However, SharePoint Portal Server 2003 affects the way information is presented across groups and divisions, and how it is distilled for executives in the enterprise. As a result, architectural decisions are largely dependent on business objectives such as: • Personal site strategy • Portal site hierarchy • Differentiating the need for a team site versus a portal site For more information, see the Windows SharePoint Services Administrator's Guide | http://go.microsoft.com/fwlink/?linkid=19480&clcid=0x409 and the Microsoft Solution Accelerator for Intranets|http://go.microsoft.com/fwlink/?LinkId=21787
Capacity Planning for SharePoint Portal Server 2003 2

Hardware Requirements
There is no simple formula to determine the hardware requirements for a given solution because the demands that a Web site makes on its servers are the result of a complex interaction involving several factors. Consider these questions: • • • • • How many users will this solution serve at peak? (What are the typical usage profiles?) How much throughput is needed from the system (pages per second)? How much content (areas, personal sites, SharePoint sites, document libraries, documents, and lists) will the solution contain? Is high availability needed? What is the performance impact of customizations?

Unless you have more specific data upon which to base the capacity planning, expect that every 1,000 users will require one page per second peak throughput.

Deployment Scenarios
Organizations can deploy SharePoint Products and Technologies in many different configurations. This second version of SharePoint Products and Technologies provides a powerful and flexible portal site infrastructure that meets the demanding scale, performance, and extensibility needs of the very largest organizations. It also delivers a preconfigured solution that is easy for smaller organizations to deploy. The number of users can often serve as the first selection criterion for organizations planning to implement SharePoint Products and Technologies solutions. The following table lists the recommended SharePoint Products and Technologies topology for optimal use of hardware resources based on the estimated number of users. Due to global network latency issues, organizations sometimes must make deployments in multiple locations. Number of users < 1,000 < 10,000 < 25,000 * < 100,000 > 100,000 Recommended topology Single server with Microsoft SQL Server 2000 Desktop Engine (MSDE) Single server with SQL Server 2000 Small farm: Front-end Web server (1), SQL (1+, optionally clustered) Medium farm: Front-end Web server or search (2), index or job (1), SQL (1+, optionally clustered) Large farm: Front-end Web server (2+), search (2+), index (1+), SQL (1+, optionally clustered)

* Most organizations of this size want a high-availability solution and, therefore, should deploy a medium farm.

Capacity Planning for SharePoint Portal Server 2003

3

Minimum High-Availability Solution For many organizations, the high availability of the solution is a more important selection criteria than the actual performance measured in pages per second. To deploy a high-availability solution, you must use a server farm. The smallest highly available SharePoint Portal Server 2003 server farm topology consists of two Web servers that also service search requests, two clustered computers running SQL Server, and a dedicated index management server. By using a server farm, it is possible to perform operations such as driver updates, operating system or software patches, Web Parts installations or upgrades, reboots, etc. in a sequenced manner without disruption to the service.

Single-Server Deployment
SharePoint Portal Server 2003 delivers a powerful and flexible portal site solution. Many organizations can address all their capacity requirements with a single server. In this scenario, the server runs all the tasks related to SharePoint Portal Server: Web, index, and search. The database that SharePoint Portal Server 2003 uses can be either MSDE or SQL Server. When deciding how many users a single-server solution can support, consider these guidelines: • MSDE is appropriate for up to 1,000 users • SQL Server is appropriate for up to 10,000 users The following table lists the hardware requirements for a single-server deployment. Server type Web, index, search, and database RAM 1 gigabyte (GB) Hard disk 100 GB CPU Dual 2.8 GHz Pentium 4

A system built with the hardware described in the preceding table should have the following performance characteristics: • Process 15 requests per second (PCA1) (including 2 searches per second) with MSDE Note MSDE has a database size limit of 2 GB and a limit of 5 concurrent jobs.

1

PCA Peak Common Action

The recommendations in this white paper are based on a combination of performance measurements of the following common portal operations:

• • • • • •

50% portal home page access 15% search operations 15% My Site private access 10% site directory access 5% topic area navigation 5% team site access

Capacity Planning for SharePoint Portal Server 2003

4

• Process 32 requests per second (including 4 searches per second) with SQL Server • Index 5 documents per second • Store up to 100,000 documents (using SQL Server) • Index up to 1 million documents (using SQL Server) • Host up to 10,000 team and personal sites • Host up to 5 portal sites (using shared services) Recommendation Running a portal site solution on a single server is a CPU-intensive task. Therefore, use a server with at least two processors. Note You are not protected from hardware failures with a single-server installation. Also, all operations that must restart critical services affect the service that end users see.

Small Farm
You can deploy SharePoint Portal Server 2003 on a small farm to free the front-end Web server from SQL Server tasks. The following table lists the hardware requirements for a small farm deployment. Server type Web and search servers Database server RAM 2 GB 2 GB Hard disk 200 GB 200 GB Number of computers 1 1 CPU Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4

A system built with the hardware described in the preceding table should have the following performance characteristics: • Process 37 requests per second (including 5 searches per second) • Index 5 documents per second • Store up to 100,000 documents • Index up to 1 million documents • Host up to 10,000 team and personal sites • Host up to 5 portal sites (using shared services) Recommendation Running a portal site solution on a single server is a CPU-intensive task. Therefore, use a server with at least two processors.

Capacity Planning for SharePoint Portal Server 2003

5

Medium Farm
You can deploy SharePoint Portal Server 2003 on server farms to address the performance, scale, and high-availability needs of very large organizations. The following table lists the hardware requirements for a medium farm deployment. Server type Web and search servers Database server Index management server RAM 2 GB 2 GB 2 GB Hard disk 200 GB 200 GB 100 GB Number of computers 2 1 1 CPU Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4

A system built with the hardware described in the preceding table should have the following performance characteristics: • Process 80 requests per second (PCA), including 12 searches per second • Index 10 documents per second • Store up to 1 million documents • Index up to 5 million documents • Host up to 50,000 SharePoint sites and personal sites • Host up to 25 portal sites using shared services • Host up to 10 portal sites not using shared services Recommendation If you deploy a medium or large farm, equip your servers with more than one network card for better throughput. For more information, see the Microsoft Solution Accelerator for Intranets|http://go.microsoft.com/fwlink/?LinkId=21787

Large Farm
The SharePoint Portal Server 2003 solution can scale to the largest usage scenarios. The following table lists the minimum hardware requirements for a large farm deployment.
Server type Web servers Search servers Database server Index management server RAM 2 GB 2 GB 2 GB 2 GB Hard disk 100 GB 200 GB 200 GB 100 GB Number of computers 2 2 1 1 CPU Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4 Dual 2.8 GHz Pentium 4

Capacity Planning for SharePoint Portal Server 2003

6

A system built with the hardware described in the preceding table should have the following performance characteristics: • Process 100 requests per second (PCA) including 15 searches per second • Index 10 documents per second • Store up to 1 million documents • Index up to 5 million documents • Host 50,000+ SharePoint sites and personal sites • Host up to 25 portal sites using shared services • Host up to 10 portal sites not using shared services You can extend this topology by adding more hardware as needed. For example, in the test lab, extending the large farm to: • • • • 14 load-balanced front-end Web servers (dual 2.8 GHz, 2 GB RAM), 4 search servers (dual 2.8 GHz, 2 GB RAM), 2 index or job servers (dual 2.8 GHz, 2 GB RAM) and 1 back-end SQL server (quad 1.9 GHz, 4 GB RAM) resulted in: o o o o 625 requests per second during PCA 852 pages per second portal site home page throughput 1,105 pages per second topics page throughput 856 pages per second team site home page throughput

Shared Services
Depending on the divisional structure and geographic locations in your organization, you may need multiple server farms. Dedicated farms supporting specific types of SharePoint sites benefit organizations that must: • Address throughput and availability requirements for the portal site and team Web sites independently • Enforce different security and customization standards for the portal site and the team Web sites • Address the need for a large number of portal sites or centralized personal sites by using shared services Shared services have a small negative effect on the overall throughput of a SharePoint Portal Server 2003 deployment, up to about 10 percent throughput cost at 50 child portal sites. Most of the cost of shared services is memory consumed by multiple portal sites. The memory consumption of 50 portal sites is typically 2 GB; it grows to 4 GB for 100 portal sites. Recommendation If you plan to deploy multiple portal sites, use shared services.
Capacity Planning for SharePoint Portal Server 2003 7

Scalability Recommendations
SharePoint Portal Server 2003 depends on several key hardware resources to ensure optimal performance. In general, the most important resource for responding to increased load is CPU capacity. Note Insufficient RAM, hard disk capacity, or network throughput can result in servers falling short of the ideal performance that their CPU capacity suggests. Plan for hardware that delivers the CPU capacity and supporting resources that satisfy your requirements based on the information in this white paper. You can evaluate the throughput capacity of portal sites in many different ways. It is important to understand those throughput characteristics—Web page throughput, search throughput, and index throughput—that have the most significant impact on the performance of a portal site deployment. The following sections provide detailed recommendations for several different deployment scenarios.

Web Page Throughput
Web page throughput is a metric that can be hard to predict. Usage that drives Web page throughput can vary greatly from hour to hour and from day to day. SharePoint Portal Server 2003 is designed to provide a high-performance solution that can accommodate dramatically varying throughput needs. Conservative recommendations for capacity planning assume that, on average, the portal site deployment runs at 10 percent of total capacity. This enables the deployment to successfully respond to unusual high-demand periods. There are many models and formulas for estimating the number of pages per second required to support a given number of users. However, it is not always clear what the term "number of users" means for an organization. It is common to refer to the number of users that could potentially use the portal site as the "number of named users." It is also common to refer to the number of users that may actively use the portal site as the "number of simultaneous users." It is extremely difficult to make a reliable prediction of the number of simultaneous users, or the number of pages per second required to support them. To help determine the required throughput of a portal site solution, organizations can use the following formula:
number of users × percent of active users per day × × number of operations × per active user per day peak factor

360,000

number of hours per day

Capacity Planning for SharePoint Portal Server 2003

8

The following table explains the variables used in the formula. Term Number of users Percent of active users per day Definition The total number of users that may have access to the solution The percentage of the total number of users who might use the portal site solution during any particular day. Typically, this figure is approximately 25 percent, but it may vary from 10 to 75 percent. The number of operations that a typical user does on the portal site during a typical day. An operation is an action such as viewing the home page, searching, retrieving documents, etc. Typically, this number is approximately 10, but it may vary depending on the organization. An approximate number that estimates the extent to which the portal site throughput exceeds the average throughput. This number typically ranges from 5 to 10. The number of hours during which most activity occurs. This number typically ranges between 6 and 14 hours.

Number of operations per active user per day Peak factor

Number of hours per day

The number 360,000 is determined by: 100 (for percent conversion) × 60 (number of minutes in an hour) × 60 (number of seconds in a minute) You can use these quantitative descriptions of a portal site deployment to estimate the required peak throughput. For example, a company with 10,000 users (of which 40 percent per day are active, performing an average of 20 operations) with a peak factor of 6 and 12 hours as the number of hours per day during which most activity occurs, needs 11 pages per second throughput. 10,000 × 40 × 20 ×6 360,000 × 12

= 11.11

Search Throughput
Use the total Web page throughput to estimate the number of content searches executed per second. Conservative recommendations for capacity planning assume that 10 percent of all Web pages viewed result in content searches.

Index Throughput
The rate at which content changes across your organization determines the rate at which to update the content index. In general, assume that 10 percent of the entire corpus must be updated in the index every 24 hours. While it is extremely rare for 10 percent of content to actually change every 24 hours, this recommendation allows the portal site to complete both large additions of content and strategic full updates of the index in a timely fashion.
Capacity Planning for SharePoint Portal Server 2003 9

The index throughput affects the performance of both the search and alerts mechanisms on the portal site, since these are dependent on an up-to-date index. Recommendation The index throughput should be capable of updating 10 percent of the entire corpus in the index every 24 hours.

High Availability
As a central source for important business information and applications, portal site deployments are frequently an important resource for an organization and can be classified as "mission critical." Many organizations choose to deploy a server farm to ensure portal site availability regardless of actual throughput requirements. Organizations typically deploy a server farm to ensure high availability rather than high Web page throughput. Recommendation If your organization classifies the portal site as a critical resource, consider deploying a server farm.

Storage
SharePoint Portal Server 2003 stores data in SQL Server and full-text indexes in the file systems on the search and index management servers. In general, the most important characteristics for determining the amount of storage space required are the total size of the documents stored on the portal site and the total size of the documents included in the portal site index. The following table illustrates the storage requirements for the server roles in a SharePoint Portal Server solution. Server role Database Index Search Required storage 200% of the total size of all documents stored on the portal site 50% of the total size of all documents included in the indexes on that server 100% of the total size of all the documents indexed

For example, a portal site that stores 1 million documents with an average document size of 100 kilobytes (KB) stores 100 GB of document data and, thus, requires 200 GB of storage space. Adding new portal sites or team sites does not in itself consume much disk space. Each new portal site (without content) consumes approximately 20 megabytes (MB) of disk space (in the database), whereas a new site, personal site, or portal site area (without content) consumes less than 200 KB of disk space (in the database). Recommendation Use the preceding table to compute your storage needs. Multiply the results by a factor of 1.5 to 3 to accommodate for future growth.

Other Recommendations
• For more than one portal site, use shared services. This results in a lower memory footprint, and requires no additional servers.
10 Capacity Planning for SharePoint Portal Server 2003

• •

Try to consolidate to a few portal sites, typically along geographic or organizational boundaries. Use areas for navigation and hierarchical security. In many cases, you can use areas to store divisional information rather than creating separate portal sites for divisions.

Common Operations
This section describes the performance impact of some common portal site operations.

Authentication
Performance tests of SharePoint Portal Server 2003 authentication mechanisms indicate similar performance for Anonymous authentication and Integrated Windows authentication. Secure Sockets Layer (SSL) usage causes approximately a 10 percent performance impact on the portal site common operations throughput. Using Basic authentication gives a 10 percent performance boost. However, to help ensure security, use either SSL or Integrated Windows authentication as the authentication mechanism.

Customizations
SharePoint Portal Server 2003 design and engineering ensures optimal use of Web server and SQL Server resources. The architecture is flexible and allows for different customization approaches.

Custom Web Parts
You can easily extend the functionality of SharePoint Portal Server 2003 by creating custom Web Parts. When you create custom Web Parts, test them carefully to ensure that they make efficient use of both Web server and SQL Server resources, and that they do not have a negative impact on the SharePoint Portal Server 2003 deployment. Web Parts that are not well designed or well written can reduce the throughput capacity of a portal site deployment significantly. If, for example, a portal site serves 24 pages per second, each page is served in approximately 40 milliseconds. Therefore, all Web Parts on that page must be rendered in that time. You can test Web Parts by using code profiling, database profiling, or load simulation. For more information about code profiling Web applications with Microsoft Visual Studio® .NET, see the Microsoft Press book Performance Testing Microsoft .NET Web Applications |http://go.microsoft.com/fwlink/?LinkId=21963&clcid=0x409 and ASP.NET Optimization on the Microsoft Developer Network (MSDN) | http://go.microsoft.com/fwlink/?LinkId=21964&clcid=0x409. For more information about profiling database applications, see the Microsoft Press book Microsoft SQL Server 2000 Performance Tuning Technical Reference | http://go.microsoft.com/fwlink/?LinkId=21965&clcid=0x409 and Optimizing Database Performance on MSDN|http://go.microsoft.com/fwlink/?LinkId=21966&clcid=0x409. Microsoft Press books and MSDN also provide information about load simulation. Recommendation Test all custom Web Parts carefully by using code profiling, database profiling, and load simulation before deploying to production servers.
Capacity Planning for SharePoint Portal Server 2003 11

Event Handlers
Developers can build solutions that use the event mechanisms provided by SharePoint Portal Server document libraries. Performance of event handlers can significantly affect portal site throughput. Test your event handlers carefully to ensure that they make efficient use of resources and do not have a negative impact on the SharePoint Portal Server 2003 deployment.

Modified Pages
SharePoint Portal Server 2003 stores some of its basic page and template information in the file system on the front-end Web server. These pages, which have not been customized, and metadata are called “ghosted pages.” When a page is modified, it is written to the database and read from there. The performance impact of reading these pages from the database rather than from the disk is approximately 10 percent.

Search
Search performance depends on the number of documents and properties in the indexes, the number of content indexes, and the complexity of the search query. Search performance also depends on the index throughput, because search requires an up-to-date index. The total number of queries performed when searching is equal to the number of searches multiplied by the number of content indexes. Each search issued will query each content source or index once. The expected search throughput on a medium farm with 5 million documents is approximately 20 queries per second.

Security
There is no noticeable performance impact on throughput when accessing the portal site with different access rights. Generally, the less access a user has to a SharePoint Portal Server 2003 portal site, the fewer server resources are needed.

Windows Security Groups for Large Sites
Because distribution groups that are used to set up the initial membership for team sites are expanded and reflect only the initial distribution group membership, security groups are useful for maintaining membership for larger sites.

Capacity Planning for SharePoint Portal Server 2003

12

Distribution groups work well for smaller sites or sites that have a life span during which membership is unlikely to change. Security groups are not expanded and, therefore, permissions will reflect recent changes made in Active Directory®. Note Only security groups or individuals can be listed as members on portal sites.

Asynchronous Operations
This section describes the performance impact of some portal site background operations. Recommendation Schedule asynchronous operation tasks during off-peak hours to minimize the performance impact on the solution.

Audiences
The performance impact of audience calculation on portal site performance is typically less than 10 percent. In the test labs, the throughput impact of audience calculation on a medium farm measured 110 pages per second for a home page access without audience calculation, and 106 pages per second with audience calculation turned on. Audience calculation is a disk-intensive operation and, therefore, may compete with other disk-intensive operations such as indexing.

Backup
Usually, SharePoint Portal Server 2003 backup performance is approximately 4 to 6 MB per second. Backup is a disk I/O-bound operation and performance depends on the location of the backup media (local disk or network share). So, for example, if the portal site contains 1 GB of content, the expected restore time is: 1,000 MB 5 MB/s = 200 s ≈ 3 min

The backup process effect on the portal site throughput is typically 5 percent.

Indexing
The overall performance of the indexer depends on the following four areas: propagation, merging, indexing and alerts. The indexing process is affected not just by the number of documents indexed and their location, but also by the number of alerts present on the content that is indexed. Having more than four indexes on each indexer in a farm configuration is not recommended. This is partly because cross-index queries are slower and have less accurate relevance, and also because of the performance impact of the propagation and merging of indexes to the search server. However, keeping content with stringent freshness requirements on a separate content index allows it to be propagated more quickly.

Capacity Planning for SharePoint Portal Server 2003

13

After the index management server updates the content index file, it is copied to the search server and merged with the other content index files. The performance of the indexes degrades when the number of documents in the index exceeds 5 million documents. The indexing process uses a high number of database connections; therefore, using MSDE for a solution with a large number of documents is not recommended, because MSDE provides for a maximum of five concurrent jobs. In the test labs, the performance of the crawl is approximately 33 documents per second on a dual processor index management server. When 100,000 subscriptions were added to a document mass of 2,500,000, the degradation of the indexer performance was approximately 17 percent. Recommendations • • • • • Have no more than four indexes on each indexer in a farm configuration. Keep content with stringent freshness requirements on a separate content index. Limit documents in an index to 5 million. Limit alerts on a portal site solution to 1 million. Do not use MSDE for a solution that contains a large number of documents.

Index Propagation
The amount of time required to propagate an index to the search server can vary depending on the number of documents included in the index and the amount of metadata in the index. Typically, the performance of index propagation is approximately 2.5 MB per second.

Profile Import
The profile import process reads data from the Active Directory directory service to populate user information into the SharePoint Portal Server databases. This is a pure read-only operation that does not modify the Active Directory in any way. On a medium farm, the expected performance of the profile importer is approximately 30 profiles per second.

Restore
Usually, the performance of the SharePoint Portal Server 2003 restore is approximately 4 MB per second. Restore is a disk I/O-bound operation and performance depends on the location of the media (local disk or network share) from which the restore is performed, and whether the restore is done to a local or remote SQL Server. So, for example, if the portal site contains 1 GB of content, the expected restore time is: 1,000 MB 4 MB/s = 250s ≈ 4 min

Capacity Planning for SharePoint Portal Server 2003

14

Long-Running Operations
This section describes the performance impact of some end-user–driven portal site operations.

Folder Renames
The performance of a folder rename operation depends on the number of items in the folder. If the number of items is large, perform these operations during off-peak hours.

Other Long-Running Operations
The performance of all operations that affect multiple items in the solution depends directly on the number of items affected. Such operations include deleting multiple documents, uploading multiple documents, renaming topic areas, and deleting topic areas.

Infrastructure Operations
This section describes the performance impact of some basic portal site operations.

Single Sign-on Operations
SharePoint Portal Server has built-in single sign-on (SSO) support for writing solutions that access different back-end systems. These solutions store credentials that can be retrieved programmatically later. On a medium farm, the portal site can retrieve approximately 100 credentials per second and store approximately 90 credentials per second using the SSO interfaces.

Web Services
For planning purposes, consider Web service requests equivalent to page requests.

Planning for Growth
Capacity planning is an ongoing process. It requires continually monitoring the use of the servers to ensure that there are sufficient resources for an optimal user experience. Over time, most deployments experience a significant growth in both the number of users and the amount of content stored in the solution.

Capacity Planning for SharePoint Portal Server 2003

15

SharePoint Portal Server 2003 can use multiprocessor servers and multiserver farms. Administrators can easily enlarge deployments to address changing requirements by adding hardware resources in any of the following categories: • Processors, random access memory (RAM), and storage capacity of existing servers • Web servers • Computers running SQL Server • Search servers • Index management servers Monitoring the system allows you to find possible system bottlenecks. After remedying a bottleneck, continue monitoring the process to find the next bottleneck.

CPU Consumption
The most important hardware resource for handling increased load in SharePoint Portal Server 2003 is CPU capacity.

Adding a New Front-End Server
Since the throughput of most portal site operations is constrained by the total CPU capacity available on the front-end server, organizations can benefit by adding extra front-end CPU capacity to the solution. The following figure illustrates this point. The throughput results are compared with the total CPU capacity of the front-end Web servers for each of the portal site topologies. All topologies used the same SQL back-end server hardware. The throughput capacity of SharePoint Portal Server 2003 shows a linear increase as CPU capacity is added.

Throughput per topology
160

Throughput (pages/sec)

140 120 100 80 60 40 20 0 5 7.5 10 12.5 15 Sm all Farm Single Server Medium Farm Large Farm

Large Farm +WFe

17.5

20

Front-end Web GHz

Capacity Planning for SharePoint Portal Server 2003

16

Adding a New Back–End SQL Server
Adding front-end capacity improves the throughput until the back-end SQL server becomes the limiting factor, as shown in the following figure.

Throughput per front-end Web servers (using 1 back-end SQL Server) 300 250 Throughput (pages/sec) 200 150 100 50 0 0 1 2 3 4 5 6 7 Number of front-end Web servers
As you see, the performance gains of adding front-end Web servers decrease after the addition of the fourth server. The optimal ratio between front-end CPUs and back-end (SQL) CPUs is approximately 4:1. Recommendation If you plan to add more front-end servers, also add back-end SQL servers in the same optimal 4:1 proportion.

Adding a New Indexer
Organizations can decrease the time is takes to crawl for incremental updates and deliver alerts by adding a new indexer to the solution.

Adding Content
Adding a large number of items to a document library has performance implications on the content rendering of the document library. Adding a large number of documents into a single document library can also result in a degraded performance on the indexer that indexes the content, since any modification to an item in a document library causes re-indexing of that document library.

Adding a Site
The actual number of sites does not affect the performance of the portal site significantly. You can expect approximately a 5 percent decrease in the common operations throughput for every 50,000 sites. Performance of the Site Directory page
Capacity Planning for SharePoint Portal Server 2003 17

on the portal site is affected since the page showing the directory information must enumerate through the Site Directory to render its content.

Adding a Portal Site
The requirements of a full portal site are larger than those of a site because a number of operations (such as indexing, profile imports, etc.) are performed on a portal site that are not performed on a site. Therefore, adding more portal sites increases the CPU and memory requirements for the solution. The PCA throughput goes down by approximately 10 percent on a solution with 50 portal sites running on the same farm.

Disk Consumption
A typical SharePoint Portal Server 2003 solution grows either by adding new documents or indexes to the existing portal site, or by adding new sites or portal sites to the solutions.

Adding a New User Profile
Adding a user profile consumes approximately 7 KB on the database.

Adding Content
Adding content increases the disk space usage on the system. The increase consists of not only the actual added data, but also the size of the indexes with the new content. Recommendation To improve performance, run appropriate administrative tasks on both the SQL server databases and the file system to reduce fragmentation. Also, after importing large amounts of data, re-index the site database tables. For more information, see the Microsoft Solution Accelerator for Intranets|
http://go.microsoft.com/fwlink/?LinkId=21787

Adding a New Content Database
By default, each content database holds 15,000 sites. Recommendation Limit the number of SharePoint sites to 50,000 per content database.

Adding New Sites
Adding new sites has minimal impact on disk consumption. It is the actual content in the created sites that affects disk consumption.

Adding a Portal Site
Adding more portal sites to the solution increases the disk space requirements, since the portal site contains search indexes. If the server farm is not part of a shared services environment, the server farm supports up to 15 portal sites. If the server farm provides or uses shared services, the server farm supports up to 100 portal sites.
Capacity Planning for SharePoint Portal Server 2003 18

Internet Information Services (IIS) limits the number of Web sites running on one server to 64. For information about how to increase this number, see the Microsoft Office SharePoint Portal Server 2003 Administrator's Guide|
http://go.microsoft.com/fwlink/?LinkId=21967&clcid=0x409.

Network Consumption
On a 100-MB network, the SharePoint Portal Server 2003 Web front-end machines usually consume just a small fraction of the total network capacity. Peak network consumption in the traffic between servers in a server farm occurs when the indexed content is propagated to the search server while indexing and page serving is occurring. The maximum network utilization encountered in the test labs during peak throughput performance runs was approximately 30 percent. Therefore, deploying a farm on a 100-MB-per-second network should ensure that network contention is not an issue. Recommendation Use at least a 100-MB network between servers in a server farm. Equip the Web servers in a farm with two network cards—one for user requests and one for SQL Server and search network traffic.

Memory Consumption
Another key resource in a SharePoint Portal Server 2003 installation is memory. If the solution has insufficient memory available, its performance deteriorates. The different portal operations have different memory needs.

Adding an Alert
Adding a search alert consumes approximately 2 KB of memory in the search process for each search alert, whereas the other alerts consume approximately 0.5 KB of memory. These numbers must be multiplied by the number of indexes on the server to determine the total memory consumption.

Adding Content or Sites
Adding content, new sites, or new portal sites not only consumes more disk space on the solution, but it also increases memory usage due to indexing, etc. Uploading large files consumes memory on the server since the entire file is loaded into memory before it is stored into the SQL Server database.

Adding a Portal Site
The memory consumption of 50 portal sites is typically 2 GB; it grows to 4 GB for 100 portal sites.

Using Shared Services
Most of the cost of shared services is memory consumed by multiple portal sites.

Capacity Planning for SharePoint Portal Server 2003

19

Table of Boundaries
It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good. The following table lists some of the SharePoint Portal Server objects and describes their recommended use. "Typical" indicates comfortable and well tested; "maximum" indicates that the system can support that number, but not without some performance ramifications or special configurations. An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit. Object Portal sites (full) Portal sites (child) Areas Best Bets Area depth User profiles Audiences Audience memberships SSO credentials Search indexes Content sources Search scopes Indexed documents per content index Indexed documents Thesaurus entries Alerts Team sites Personal sites Typical 2 10 1,000 1,000 5 50,000 500 500,000 100,00 3 25 25 100,000 2,500,000 1,000 50,000 10,000 10,000 Maximum 15 * 100 * 10,000 25,000 20 * 1,000,000 10,000 5,000,000 100,000 32 250 250 * 5,000,000 20,000,000 10,000 1,000,000 250,000 250,000

Capacity Planning for SharePoint Portal Server 2003

20

Summary
Built on the foundation of Windows Server 2003, SharePoint Portal Server 2003 extends Windows SharePoint Services by adding entire classes of functionality to the enterprise, connecting people, teams, and knowledge across business processes. You can deploy the scalable and distributed architecture on a single server or server farm, by using top-down or bottom-up deployment, and in a centralized or decentralized model. The flexible deployment model, together with significant enhancements in scalability, performance, availability, and manageability, enable enterprise business solutions to start small and grow with an organization's needs.



Capacity Planning for SharePoint Portal Server 2003

21

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, SharePoint, Visual Studio, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Capacity Planning for SharePoint Portal Server 2003

22