Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server)
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
In this article:
Key characteristics
Test environment
Usage profile
Recommendations
This performance and capacity planning scenario incorporates a single Windows SharePoint Services 3.0 farm used for collaboration and document management in an enterprise environment.
Key characteristics
Key characteristics describe environmental factors, usage characteristics, and other considerations common to the scenario.
The key characteristics for this scenario include:
**Authentication/authorization **Typically users are authenticated and sites and content are secured either by using security groups or by granting access to individual users based on their user account. Integrated Windows authentication is used in this scenario.
**Both common (read) and complex (read/write) user operations **In a collaboration environment, users view and contribute to content. Throughput targets for this scenario are designed to ensure reasonable response times for complex user operations, such as uploading or downloading a document.
**Data and site growth over time **In addition to estimating the initial data volume, a Windows SharePoint Services 3.0 collaboration environment must also allow for data and site growth over time. A server farm that is sized only for the initial data volume can quickly be outgrown.
**User response times **Target user response times for common, uncommon, long-running, and rare operation are listed in the User response time table at the end of the Plan for software boundaries (Windows SharePoint Services) section, are targeted. Some organizations might tolerate slower user response times or might require faster user response times. The expected user response time is a key factor that determines overall throughput targets. (Throughput is defined as how many requests the server farm can process per second). A greater number of users requires a higher throughput target to achieve the same user response time.
**User concurrency **A concurrency rate of 10% is assumed, with 1% of concurrent users making requests at a given moment. In other words, for 10,000 users, the assumption is that 1,000 users will be actively using the solution at the same time, and that 100 users will be actively making requests.
**Long-running asynchronous tasks **Tasks such as indexing content and backing up databases add a performance load to the server farm. The general performance characteristics of sample topologies assume that these tasks are running during off-peak hours, such as overnight. Thus, user response rates during business hours are not affected.
Test environment
Testing for this scenario was designed to help develop estimates of how different farm configurations respond to changes in a variety of factors, including number of concurrent users, user operations, and the number of objects such as site collections, sites, libraries, and lists.
It is important to note that although certain conclusions can be drawn from the test results, the specific capacity and performance figures in this section will vary in real-world environments. These results are intended to provide a starting point for the design of a properly scaled environment. After you have completed your initial system design, test the configuration to determine if your system will support the factors inherent in your environment.
For more information about testing your deployment, see Tools for performance and capacity planning (Windows SharePoint Services).
Assumptions
- **64-bit architecture **Only 64-bit servers were used in the test environment. Although Windows SharePoint Services 3.0 can be deployed on 32-bit servers, Microsoft recommends that you employ 64-bit servers in Windows SharePoint Services 3.0 farm deployments. See the 64-bit vs. 32-bit section in the article About performance and capacity planning (Windows SharePoint Services) for more information.
Lab Topology
In order to provide a high level of test-result detail, several farm configurations were used for testing, ranging from a stand-alone computer to eight Web servers with single and clustered computers running Microsoft SQL Server 2005. Testing was performed with eight client computers simulating from 32 through 256 user connections.
The following table lists the specific hardware used for testing.
| Computer role | Hardware |
|---|---|
Web server |
2 dual-core Intel Xeon 2.8 gigahertz (GHz) processors 4 gigabytes (GB) RAM |
Database server |
4 dual-core Intel Xeon 2.8 GHz processors 32 GB RAM |
Client computer |
1 Pentium 3 1.2 GHz processor 1 GB RAM |
A gigabit (1 billion bits/sec) network was used in the test environment.
Usage profile
The following table shows the usage profile for the Windows SharePoint Services 3.0 collaboration test environment. Note that the usage profile for the Windows SharePoint Services 3.0 collaboration scenario assumes that the majority of user actions are within team sites.
Search within Windows SharePoint Services is scoped to a site collection. Consequently, search actions do not substantially affect throughput.
The following table shows the percentage of throughput consumed by each listed type of user operation in the test environment.
| Operation | Percentage of throughput |
|---|---|
Get home page |
15.00 |
Get cached document |
15.00 |
Get static document |
15.00 |
Get list page (HTML) |
10.00 |
Get list page (grid) |
10.00 |
Get list form |
7.00 |
404 errors |
5.00 |
Insert list item |
2.00 |
Edit list item |
2.00 |
Delete list item |
2.00 |
Insert document |
2.00 |
Synchronize with Outlook |
2.00 |
Delete document |
2.00 |
List URLs |
2.00 |
DAV (Distributed Authoring and Versioning) open document for edit |
1.00 |
DAV save document |
1.00 |
FPRPC (FrontPage Server Extensions Remote Procedure Call) open document for edit |
1.00 |
FPRPC Save document |
1.00 |
Short-term check-out |
1.00 |
Incoming e-mail |
1.00 |
RSS (Really Simple Syndication) |
1.00 |
Start workflow |
0.75 |
Workflow task completion |
0.75 |
Add/remove user |
0.50 |
Recommendations
This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and performance characteristics of the starting topology that you created in Plan for redundancy (Windows SharePoint Services) article) and to determine whether you need to scale the starting topology out or up.
Hardware recommendations
The following table lists the recommended hardware for Web servers and database servers. For more information about minimum and recommended system requirements, see Determine hardware and software requirements (Windows SharePoint Services).
Note
Memory requirements for Web servers and database servers are dependent on the size of the farm, the number of concurrent users, and the complexity of features and pages in the farm. The memory recommendations in the following table may be adequate for a small or light usage farm, but memory usage should be carefully monitored to determine if more memory must be added.
| Computer role | Recommended hardware |
|---|---|
Web server |
Dual 2.5 GHz or faster processors (3 GHz or faster recommended) 2 GB RAM minimum recommended 3 GB of available disk space DVD drive, local or network accessible 1024x768 or higher resolution monitor |
Database server |
Dual 2.5 GHz or faster processors (3 GHz or faster recommended) 4 GB RAM minimum recommended Hard disk space based on a 1:1.2 ratio of content to database capacity. That is, if you plan for 100 GB of content, you need at least 120 GB of available disk space, plus additional space for transaction logs. DVD Drive, local or network accessible 1024x768 or higher resolution monitor |
Starting-point topologies
You can estimate the performance of your starting-point topology by comparing your topology to the starting-point topologies that are provided in Plan for redundancy (Windows SharePoint Services). So doing can help you quickly determine if you need to scale your starting-point topology to meet your performance and capacity goals.
Capacity and performance of scaled-out topologies
To increase the capacity and performance of one of the starting-point topologies, either scale up by implementing server computers with greater capacity or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale a topology for the collaboration scenario:
To accommodate greater user load, add Web server computers.
To accommodate greater data load, add capacity to the database server role by increasing the capacity of a single (clustered or mirrored) server, by upgrading to a 64-bit server, or by adding clustered or mirrored servers.
Maintain a ratio of no greater than eight Web server computers to 1 (clustered or mirrored) database server computer.
Estimating throughput targets
Throughput is the number of operations that a server farm can perform per second. Ideally, the number of operations that are requested per second is lower than the number that is targeted for a given level of performance. If the number of operations that is requested exceeds the targeted number, user actions and other operations take longer to complete.
Throughput is measured in requests per second (RPS). RPS measurements can be converted to the total number of users by using a model of typical end-user behavior. Like many human behaviors, there is a broad range of "typical" behavior. The user model for Windows SharePoint Services 3.0 has the following two variables:
Concurrency - The percentage of users that are actively using the system.
Request rate — The average number of requests per hour that an active user generates. Four levels of user behavior are shown in the following table.
You can calculate a rough throughput guideline for typical load in the following way:
Number of users*percentage of users who are active/request rate
For example, for 1,000 users, the following values result:
Simultaneous users = 1,000 * 10% = 100
Estimated requests per user per hour = 36 = 1 request per user per 100 seconds
Throughput = simultaneous users/request rate = 100/100 = 1 RPS
Therefore, 1 RPS can support up to 1,000 users, each making 36 requests per hour.
The following table describes throughput targets for four levels of user load.
| User load | Request rate | Supported users |
|---|---|---|
Light |
20 requests per hour. An active user will generate a request every 180 seconds. |
Each response per second of throughput supports 180 simultaneous users and 1,800 total users. |
Typical |
36 requests per hour. An active user will generate a request every 100 seconds. |
Each response per second of throughput supports 100 simultaneous users and 1,000 total users. |
Heavy |
60 requests per hour. An active user will generate a request every 60 seconds. |
Each response per second of throughput supports 60 simultaneous users and 600 total users. |
Extreme |
120 requests per hour. An active user will generate a request every 30 seconds. |
Each response per second of throughput supports 30 simultaneous users and 300 total users. |
If your organization has an existing collaboration solution, you can view the IIS logs to determine the usage patterns and trends in your current environment. For more information about parsing IIS logs, see Analyzing Log Files (IIS 6.0) https://go.microsoft.com/fwlink/?LinkId=78825&clcid=0x409.
If your organization is planning a new collaboration solution deployment, use the information in the following section to estimate your usage patterns.
Estimate throughput targets
The estimated throughput performance of the server farms presented in the previous section is based on the following assumptions:
User response rate of <1 second for common operations
User concurrency rate of 10%
Indexing operations running within an overnight time window of 12 hours
Use the information in this section to change the value of these assumptions to accommodate your organization’s characteristics. The result might be a different throughput target for your organization.
Test results: Throughput by farm configuration
The table in this section shows test results for a variety of user operation profiles using the hardware listed in Test environments earlier in this article. The number of user connections is a fixed parameter that was used during testing.
The following table shows test results for both read-write mix and read-only user operations.
| Farm configuration | RPS | Total number of user connections | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
Light usage |
Typical usage |
Heavy usage |
Extreme usage |
||||
Mix |
Read |
Mix |
Read |
Mix |
Read |
Mix |
Read |
Mix |
Read |
|
1 by 1 |
50 |
100 |
90,000 |
180,000 |
50,000 |
100,000 |
30,000 |
60,000 |
15,000 |
30,000 |
2 by 1 |
99 |
185 |
178,200 |
333,000 |
99,000 |
185,000 |
59,400 |
111,000 |
29,700 |
55,500 |
3 by 1 |
115 |
265 |
207,000 |
477,000 |
115,000 |
265,000 |
69,000 |
159,000 |
34,500 |
79,500 |
4 by 1 |
120 |
275 |
216,000 |
495,000 |
120,000 |
275,000 |
72,000 |
165,000 |
36,000 |
82,500 |
5 by 1 |
136 |
280 |
244,800 |
504,000 |
136,000 |
280,000 |
81,600 |
168,000 |
40,800 |
84,000 |
6 by 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
7 by 1 |
134 |
290 |
241,200 |
522,000 |
134,000 |
290,000 |
80,400 |
174,000 |
40,200 |
87,000 |
8 by 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
The following graph shows changes in throughput for both read-write and read-only operations when the number of front-end Web servers changes. Note that this graph is not based on the test results from the above table. It is intended to illustrate the general trend in performance when front-end Web servers are added to a system.
Note that systems that only support read operations, such as a static portal site, can maintain a higher level of throughput than a system that supports both read and write operations.
.gif "Windows SharePoint Services performance example")
Estimate user response time
First, determine if your organization can tolerate a slower user response time or if your organization demands a faster user response time. Response times are categorized in the following way:
Slow (3-5 seconds) User response times can slow to this rate without issue.
Recommended (1-2 seconds) The average user response time target.
Fast (<1 second) For organizations whose businesses demand speed.
Based on the user response time that most closely matches your organization’s requirements, determine the throughput target based on the number of users. Because a single-server deployment can capably serve up to 1,000 users, 500 users is the fewest listed.
The following table lists throughput targets based on user response times.
| Total users | Slow (RPS) | Recommended (RPS) | Fast (RPS) |
|---|---|---|---|
500 |
.4 |
.5 |
.7 |
1,000 |
.7 |
1.0 |
1.2 |
5,000 |
4.0 |
5.0 |
6.0 |
10,000 |
9.0 |
10.0 |
12.0 |
20,000 |
18.0 |
20.0 |
24.0 |
50,000 |
40.0 |
50.0 |
60.0 |
100,000 |
90.0 |
100.0 |
120.0 |
After you have identified the throughput target that is appropriate for your organization, re-evaluate the test data for the sample topologies to validate your choice of topology and hardware.
Estimate concurrency rate
Next, estimate your organization’s concurrency rate. Concurrency rate is the percentage of users that are using the solution at the same time. Use the concurrency rate that you expect during peak hours. The following table recommends throughput targets based on the total number of users and the concurrency rate.
The following table lists throughput targets in RPS at various concurrency rates.
| Total users | 5% concurrency rate | 10% | 15% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|---|
500 |
.25 |
.5 |
.75 |
1.25 |
2.5 |
3.75 |
5.0 |
1000 |
.5 |
1.0 |
1.5 |
2.5 |
5.0 |
7.5 |
10.0 |
5,000 |
2.5 |
5.0 |
7.5 |
12.5 |
25.0 |
37.5 |
50.0 |
10,000 |
5.0 |
10.0 |
15.0 |
25.0 |
50.0 |
75.0 |
100.0 |
20,000 |
10.0 |
20.0 |
30.0 |
50.0 |
100.0 |
150.0 |
200.0 |
50,000 |
25.0 |
50.0 |
75.0 |
125.0 |
250.0 |
375.0 |
500.0 |
100,000 |
50.0 |
100.0 |
150.0 |
250.0 |
500.0 |
750.0 |
1,000 |
After you have identified the throughput target that is appropriate for you organization based on your expected concurrency rate, re-evaluate the test data for the sample topologies to validate your choice of topology and hardware.
Estimate indexing window
Finally, verify that indexing jobs can be contained within an overnight window of 12 hours. In a Windows SharePoint Services 3.0 collaboration environment, indexing jobs typically represent the longest-running operation that is not initiated by users. You will need to perform testing in your own environment to determine the duration of indexing jobs, and whether the throughput consumed by indexing jobs interferes with your target user response times.
Estimating disk space requirements
This section provides tables that can help you estimate disk space requirements for the collaboration scenario. Disk space requirements for your hardware will vary greatly by server role and scenario, and are dependent upon data to be stored in the content database, caching requirements, and external content crawled by search. Where possible in the following discussion, numbers are filled into the formulas based on disk space requirements that can be predicted (such as the size of installation files).
First, estimate your disk space requirements by server role. Then, based on your planned topology, add up the requirements where server roles will share the same physical server computer. Finally, ensure that your hardware is appropriately sized to accommodate your disk space requirements.
Additionally, best practices for SQL Server storage should be applied to database servers. For more information, see Physical Database Storage Design (https://go.microsoft.com/fwlink/?LinkId=78853&clcid=0x409).If more than one database server is implemented, apply the SQL disk space factor separately for each search server.
Note
Operating system and program files should stored separately from data files on a separate drive or a Redundant Array of Independent Disks (RAID).
Database server disk space requirements
Use the following table to calculate disk space requirements for database servers in your farm. If more than one database server is implemented, calculate this sum separately for each search server.
| Category | Description | Number |
|---|---|---|
Operating system files |
Disk space required for Windows Server 2003 Setup and system files. For more information, see Choosing a File System for the Installation Partition (https://go.microsoft.com/fwlink/?LinkId=78866&clcid=0x409). |
4 GB |
Swap file |
The swap file size will be the same as the physical memory size, by default. |
|
SQL Server installation files |
Disk space required for SQL Server Setup and program files. For more information, see SQL Server 2005 Standard Edition System Requirements (https://go.microsoft.com/fwlink/?LinkId=78870&clcid=0x409). |
425 megabytes (MB) |
Database log files |
Disk space for log files will vary based on log settings and the number of databases. For more information, see Physical Database Storage Design (https://go.microsoft.com/fwlink/?LinkId=78853&clcid=0x409). |
|
Configuration database |
The configuration database will not grow past this size. |
1.5 GB |
Content databases |
Estimate the initial volume of content that will be stored in content databases. Consider the following factors:
|
|
Future growth |
Future growth is a key characteristic of the collaboration scenario. You should plan for twice the amount of data that you initially plan to experience. Enter a number that is appropriate for your environment. |
|
Free space |
Leave at least 25% free space for each hard disk or volume. |
|
Total |
Search server disk space requirements
Use the following table to calculate disk space requirements for search servers in your farm. If more than one Windows SharePoint Services 3.0 search server is implemented, calculate this sum separately for each search server.
| Category | Description | Number |
|---|---|---|
Operating system files |
Disk space required for Windows Server 2003 setup and system files. For more information, see Choosing a File System for the Installation Partition (https://go.microsoft.com/fwlink/?LinkId=78866&clcid=0x409). |
4 GB |
Paging file |
The paging file size will be the same as the physical memory size, by default. |
|
Windows SharePoint Services 3.0 installation files |
This number is an approximation based on a full installation. |
1.3 GB |
The Microsoft .NET Framework version 3.0 |
60 MB |
|
Content index |
Add the amount of content in content databases that will be indexed by the index server. Divide this amount by 2. The resulting number is the estimated size of the content index. |
|
Free space |
Leave at least 25% free space for each hard disk or volume. |
|
Total |
Web server disk space requirements
Use the following table to calculate disk space requirements for Web servers in your farm.
| Category | Description | Number |
|---|---|---|
Operating system files |
Disk space required for Windows Server 2003 setup and system files. For more information, see Choosing a File System for the Installation Partition (https://go.microsoft.com/fwlink/?LinkId=78866&clcid=0x409). |
4 GB |
Swap file |
The swap file size will be the same as the physical memory size, by default. |
|
Windows SharePoint Services 3.0 installation files |
1.3 GB |
|
The .NET Framework version 3.0 |
60 MB |
|
Free space |
Leave at least 25% free space for each hard disk or volume. |
|
Total |
Performance monitoring
Using performance counters to monitor the health of your system is an important factor in determining when you need to scale your system up or out. Use the information in the following tables to determine what performance counters to monitor, and to which process the performance counters should be applied.
Web server
The following table shows performance counters and processes to monitor for Web servers in your farm.
| Performance counter | Apply to process | Notes |
|---|---|---|
% Processor time |
Total |
Shows the percentage of elapsed time that this thread used the processor to execute instructions. |
% Memory utilization |
Application pool |
Shows the average utilization of system memory for the application pool. You need to identify the correct application pool to monitor. The basic guideline is to identify peak memory utilization, and assign that number plus 10% to the application pool. |
Database server
The following table shows performance counters and processes to monitor for database servers in your farm.
| Performance counter | Apply to process | Notes |
|---|---|---|
% Processor time |
Total |
Shows the percentage of elapsed time that this thread used the processor to execute instructions. |
% Memory utilization |
Total |
Shows the average utilization of system memory. |
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.
See Also
Other Resources
Additional performance and capacity planning factors (Windows SharePoint Services)