Estimate performance and capacity requirements for Internet 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 Microsoft Office SharePoint Server 2007 farm used for an Internet portal presence in an enterprise environment.

Key characteristics

Key characteristics describe environmental factors, usage characteristics, and other considerations that are likely to be found in deployments based on this scenario.

The key characteristics for this scenario include:

  • **Authorization   **Internet-facing portal environments typically do not require user authentication or authorization to available resources for most users. However, there are cases in which authentication is required for the users to access certain parts of the Web site. This document provides data for pure anonymous environments, environments in which all users are authenticated by using NTLM, and environments in which 80 percent of users are anonymous and 20 percent are authenticated by using NTLM.

  • **User operations   **In this environment, all user operations are read access to the site. These operations include reading Web pages, navigating the site, and searching for information.

  • Data and site growth over time   In addition to estimating the initial data volume, a Office SharePoint Server 2007 Internet portal 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 article Plan for software boundaries (Office SharePoint Server). 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). When you have more users, you require a higher throughput target to achieve the same user response time.

  • User concurrency   User concurrency for any given Internet environment will depend on many factors. The maximum number of concurrent users in this testing was 270.

  • Long-running asynchronous tasks   Tasks such as indexing content, third-party site searches, and backing up databases can affect server farm throughput. The general performance characteristics of sample topologies assume that long-running tasks initiated by the farm administrator are running during off-peak hours, such as overnight. However, in an Internet portal environment, third-party site searches and crawling might occur at any time.

  • **Cache hit ratio   ** This document assumes a cache hit ratio of approximately 99 percent.

Test environment

Testing for this scenario was designed to help develop estimates of how Office SharePoint Server 2007 performs in an Internet portal environment.

Although certain conclusions can be drawn from the test results, the specific capacity and performance figures presented in this article will be different from the figures in real-world environments. The figures presented are intended to provide a starting point for the design of a correctly scaled environment. After you have completed your initial system design, test the configuration to determine whether your system will support the factors intrinsic to your environment.

This testing was conducted with the SharePoint 2007 Test Data Population Tool, using publicly available test data. You can download the SharePoint 2007 Test Data Population Tool and the test data used for this testing from https://go.microsoft.com/fwlink/?LinkId=92678&clcid=0x409.

For information about how to test your deployment, see Tools for performance and capacity planning (Office SharePoint Server).

Assumptions

  • 64-bit architecture   Only 64-bit servers were used in the test environment. Although Office SharePoint Server 2007 can be deployed on 32-bit servers, we recommend that you employ 64-bit servers in Office SharePoint Server 2007 farm deployments. For more information, see the 64-bit vs. 32-bit section in the article About performance and capacity planning (Office SharePoint Server).

  • **Disk-based caching is enabled   **Disk-based caching eliminatesthe need to access the database multiple times for code fragments or large binary files, such as images, sounds, and videos. Enabling disk-based caching will improve performance across your entire deployment. By default, disk-based caching is not enabled. For information about how to enable disk-based caching, see Disk-based Caching for Binary Large Objects (https://go.microsoft.com/fwlink/?LinkId=82617&clcid=0x409).

Lab Topology

In order to provide a high level of test-result detail, two farm configurations were used for testing, ranging from two to four Web servers together with a single index server and a single database server computer running Microsoft SQL Server 2005 database software. Testing was performed with twenty-seven client computers that simulated up to 270 concurrent user connections. All server computers were 64-bit, and the client computers were 32-bit.

The following table lists the specific hardware that was used for testing.

Computer role Hardware

Web server

2 dual-core Intel Xeon 2.8 gigahertz (GHz) processors

8 GB RAM

Index server

4 dual-core Intel Xeon 2.8 GHz processors

32GB RAM

Database server

4 dual-core Intel Xeon 2.8 GHz processors

32 GB RAM

Client computer

1 Pentium 4 3.2 GHz processor

1 GB RAM

A gigabit (1 billion bits/sec) network was used in the test environment. We recommend that you use a gigabit network between servers in a Office SharePoint Server farm to ensure sufficient network bandwidth.

Software

The following table shows the software that was installed on the servers used for this testing.

Important

The test results in this article depend on an Office SharePoint Server 2007 software update that was installed before testing. This software update corrects an issue with Office SharePoint Server 2007 that causes performance degradation under certain circumstances in farms that use binary large object (BLOB) caching. If you are planning to use BLOB caching in your environment, you should install this software update to maximize the performance of your farm. This software update is covered in Microsoft Knowledge Base article 939077 (https://go.microsoft.com/fwlink/?LinkId=98352).

Computer role Software

Web server

Microsoft Windows Server 2003 operating system with Service Pack 1 (SP1), Enterprise Edition with the most recent updates

Microsoft Office SharePoint Server 2007 x64

The Microsoft .NET Framework version 2.0

The .NET Framework software update KB923197 for x64

The .NET Framework software update KB925613

Windows Workflow Foundation

Index server

Windows Server 2003 with SP1, Standard x64 Edition with the most recent updates

Office SharePoint Server 2007 x64

The .NET Framework version 2.0 x64

The .NET Framework software update KB923197 for x64

The .NET Framework software update KB925613

Windows Workflow Foundation

Database server

Windows Server 2003 with SP 1, Enterprise x64 Edition with the most recent updates

Microsoft SQL Server 2005 (64-bit) database software

The .NET Framework version 2.0 x64

The .NET Framework software update KB923197 for x64

The .NET Framework software update KB925613

Windows Workflow Foundation

Client computer

  • Windows Server 2003 with SP 1, Standard Edition with the most recent updates

Microsoft Internet Explorer 6.0.3790.1830 with SP 1

Usage profile

This section shows the usage scenarios, page resources, and cache settings that were used during the test process.

Usage scenarios

The following usage scenarios were used concurrently to test throughput of the test farm. Each test consisted of a specific mix of the three scenarios according to the table later in this section. Note that although random sites were used, these sites were limited to a limited set of sites to ensure a high number of cached page hits. Images on pages containing images were up to 15 kilobytes (KB) in size.

  • **Scenario 1 **

    1. User navigates to the root site Welcome page.

    2. User navigates to a random site.

    3. User navigates to an article page that contains three images under the random site.

  • **Scenario 2 **

    1. User navigates to a random site.

    2. User navigates to an article page that contains three images under the random site.

    3. User navigates to another random site.

    4. User navigates to an article page that contains three images under the random site, making sure that this page differs from the preceding page.

  • **Scenario 3 **

    1. User navigates to the root site Welcome page.

    2. User performs a search query.

    3. User navigates to an article page that contains three images under a random site.

The following table shows the percentage of throughput consumed by each listed scenario in the test environment. Note that a negligible amount of throughput was used by background requests, but was not a performance consideration.

Scenario Percentage of throughput

Scenario 1

47.5

Scenario 2

47.5

Scenario 3

5

The following table shows the sizes of the database content, index, and caches during testing.

Resource Size

Content database

56.6 gigabytes (GB)

Number of items in the content database

  • 6,396 sites

  • 1,500,381 pages

  • 1,000 images

Index

2.88 GB

Number of items in the index

698,692

BLOB cache

10 GB

Object cache

512 MB

Page resources

The following resources existed on the Welcome pages used for testing.

  • 1 HTML field control

  • 2 image field controls

  • 1 TOC Web Part

  • 1 Summary Link Web Part

Cache settings

The following table lists the output cache settings that were used during testing of anonymous user operations.

Parameter Value

Perform ACL Check

No

Enabled

Yes

Duration

3,600

Check for Changes

No

Vary by User Rights

No

Cacheability

Public

Safe for Authenticated Use

Yes

Allow writers to view cached content

No

The following table lists the output cache settings that were used during testing of authenticated user operations.

Parameter Value

Perform ACL Check

Yes

Enabled

Yes

Duration

3,600

Check for Changes

No

Vary by User Rights

Yes

Cacheability

ServerAndPrivate

Safe for Authenticated Use

Yes

Allow writers to view cached content

Yes

The following table shows the object cache settings that were used during testing. These settings correspond to the settings on the Object cache settings page under Site Settings for an individual site in a site collection.

Section Parameter Value

Object Cache Size

Max. Cache Size (MB)

512 megabytes (MB)

Object Cache Reset

  • Object Cache Flush

Cleared

  • Object Cache Reset

  • Force all servers in the farm to flush their object caches

Cleared

Disk Based Cache Reset

Force this server to reset its disk based cache

Cleared

Cross List Query Cache Changes

Check the server for changes every time a cross list query runs

Cleared

Cross List Query Cache Changes

Use the cached result of a cross list query for this many seconds

Selected; 3600

Cross List Query Results Multiplier

Cross list query multiplier

3

The following code string defines the BLOB cache settings that were used during testing. This code string is contained in the Web.config file for the Web application. If you copy this code for use in the Web.config file on your own server, replace <drive_letter> with the drive letter that corresponds to the hard disk drive on which you plan to store the BLOB cache on your server.

<BlobCache location="<drive_letter>:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="true" />

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 the Plan for redundancy (Office SharePoint Server) and to determine whether you have to scale the starting topology out or up.

Hardware recommendations

The following table lists the recommended hardware for Web servers, index servers and database servers. For more information about minimum and recommended system requirements for Office SharePoint Server 2007, see Determine hardware and software requirements (Office SharePoint Server). For more information about estimating disk space requirements for Internet environments, see Estimating disk space requirements later in this article.

Note

Memory requirements for Web, index 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. Memory usage should be carefully monitored to determine if more memory must be added.

Note

This table has been updated to more accurately reflect the requirements for real-world environments.

Computer role Recommended hardware

Web server

4 2.5 GHz or faster processors (3 GHz or faster recommended)

16 GB RAM minimum recommended

3 GB of available disk space

DVD drive, local or network accessible

1024×768 or higher resolution monitor

Index server

Dual 2.5 GHz or faster processors (3 GHz or faster recommended)

4 GB RAM minimum recommended

3 GB of available disk space

DVD drive, local or network accessible

1024×768 or higher resolution monitor

Database server

Dual 2.5 GHz or faster processors (3 GHz or faster recommended)

4 GB RAM minimum recommended

For disk space requirements, see later in this article.

DVD Drive, local or network accessible

1024×768 or higher resolution monitor

Starting-point and scaled-out 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 (Office SharePoint Server). Doing so can help you quickly determine whether you must scale your starting-point topology to meet your performance and capacity goals.

To increase the capacity and performance of one of the starting-point topologies, either scale up by implementing server computers that have 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 an Internet portal environment:

  • 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 from a 32-bit server to a 64-bit server, or by adding clustered or mirrored servers.

  • Maintain a ratio of no greater than eight Web server computers to one (clustered or mirrored) database server computer. While the maximum ratio of Web servers to database servers we tested for this document was 4x1 (four Web servers to one database server), deployment of more Web servers or more robust hardware might yield better results in your environment.

Estimating throughput targets

Throughput is the number of operations that a server farm can perform per second. Throughput is measured in requests per second (RPS). This section provides test data that shows farm throughput for an increasing number of front-end Web servers and user connections.

Several factors can affect throughput. These include the number of users, complexity and frequency of user operations, caching, and customization of pages and Web Parts. Each of these factors can have a major effect on farm throughput. You should carefully consider each of these factors when you plan your deployment.

Because Office SharePoint Server 2007 can be deployed and configured in a wide variety of ways, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy Office SharePoint Server 2007 in a production environment.

In general, you should enable object caching and BLOB caching in an Internet portal environment. In an environment that uses pure anonymous authentication, enabling caching can improve farm performance by a factor of two or more. For more information about caching in Office SharePoint Server 2007, see Custom Caching Overview (https://go.microsoft.com/fwlink/?LinkId=82618&clcid=0x409), and see the Caching section of Additional performance and capacity planning factors (Office SharePoint Server).

Important

The test results in this article depend on an Office SharePoint Server 2007 software update that was installed before testing. This software update corrects an issue with Office SharePoint Server 2007 that causes performance degradation under certain circumstances in farms that use binary large object (BLOB) caching. If you are planning to use BLOB caching in your environment, you should install this software update to maximize the performance of your farm. This software update is covered in Microsoft Knowledge Base article 939077 (https://go.microsoft.com/fwlink/?LinkId=98352).

If your organization has an existing Internet portal solution, you can view the Microsoft Internet Information Services (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 Internet portal solution, use the information in this section to estimate your usage patterns.

Test results

The tables in this section show test results for read-only user operations using the hardware listed in Test environments earlier in this article. Note that for each farm configuration, a range of Web servers was tested with one index server and one database server. Therefore, a 2x1x1 farm configuration should be read as two (Web servers) by one (index server) by one (database server). Testing was not conducted on farms containing multiple application or database servers, or against a single-server deployment.

Testing was conducted with the following three different authentication scenarios:

  • An anonymous environment in which no authentication was used.

  • An environment in which NTLM authentication was used for every user connection.

  • An environment in which 80 percent of user connections were anonymous and 20 percent were authenticated by using NTLM.

The average number of requests per page during testing was four. Therefore, the ratio of requests per second (RPS) to pages per second (PPS) can be calculated as r=(p*4)+x where r=RPS, p=PPS and x=background requests such as requests for search queries and non-cached pages.

The number of requests per page and the time for a resource to load can vary widely depending on page complexity, the number of secondary resources called by each page resource, and many other factors. Therefore, performance estimates drawn only on the number of resources per page are not completely accurate.

These test results were captured after a brief warm-up period to allow farm performance to stabilize.

The following tables show test results for read-only user operations. Note that each test was conducted using the mix of usage scenarios described in the Usage profile section of this article.

Pure anonymous environment

The following table shows the test results for an environment in which all user connections were anonymous.

Farm size Throughput (RPS) PPS Search queries per second Miscellaneous requests (RPS)

2x1x1

2,927

717

12

2.54

4x1x1

5,612

1,388

22

3.47

NTLM authenticated environment

The following table shows the test results for an environment in which all user connections were authenticated using NTLM.

Farm size Throughput (RPS) PPS Search queries per second Miscellaneous requests (RPS)

2x1x1

632

152.6

2.8

0.33

4x1x1

1,304

328.6

5.3

0.31

80 percent anonymous, 20 percent NTLM authenticated environment

The following table shows the test results for an environment in which 80 percent of the user connections were anonymous, and 20 percent were authenticated using NTLM.

Farm size Throughput (RPS) PPS Search queries per second Miscellaneous requests (RPS)

2x1x1

1,945

481.8

8.4

1.95

4x1x1

2,946

731.8

11.9

1.3

Estimating disk space requirements

This section provides tables that can help you estimate disk space requirements for Internet portal environments. 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, numbers are filled into the formulas based on disk space requirements that can be predicted (for example, the size of installation files).

First, estimate your disk space requirements by server role. Then, based on your planned topology, for cases in which server roles share the same physical server computer, sum the disk space requirements for those roles. Finally, make sure that your hardware can 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 database 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

By default, the paging file size will be the same as the physical memory size.

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 generally not grow past this size. This is an estimated maximum size, not a hard limit.

1.5 GB

Content databases

Estimate the initial volume of content that will be stored in content databases. Consider the following factors:

  • Hard disk space for the content database is based on a 1:1.2 ratio of content size to database capacity. For example, if you plan for 100 GB of content, you need at least 120 GB of available disk space for the content database, plus additional space for transaction logs.

  • Hard disk space for the search database is based on a 1:6 ratio of index size to database capacity. For example, if your index will be 100 GB in size, you need at least 600 GB of available disk space for the search database, plus additional space for transaction logs.

  • If versioning is used for documents, a copy of each version is stored in the database, and you should increase your available hard disk space accordingly.

Future growth

You should plan for double the amount of data that you initially plan to deploy. Enter a number that is appropriate for your environment.

Free space

Leave at least 25 percent free space for each hard disk or volume.

Total

Index server disk space requirements

Use the following table to calculate disk space requirements for index servers in your farm. If more than one Office SharePoint Server 2007 index server is implemented, calculate this sum separately for each 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

By default, the paging file size will be the same as the physical memory size.

Office SharePoint Server 2007 installation files

This number is an approximation based on a full installation of any Office SharePoint Server 2007 edition.

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. 30 percent of the resulting number is the maximum estimated size of the content index.

Free space

Leave at least 25 percent free space for each hard disk or volume.

Total

Web server disk space requirements

Use the following table to calculate disk space requirements for each Web server 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

By default, the paging file size will be the same as the physical memory size.

Office SharePoint Server 2007 installation files

1.3 GB

The .NET Framework version 3.0

60 MB

Free space

Leave at least 25 percent free space for each hard disk or volume.

Total

Performance monitoring

To help you determine when you must scale your system up or out, use performance counters to monitor the health of your system. 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 and index servers

The following table shows performance counters and processes to monitor for Web and index 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 must identify the correct application pool to monitor.

The basic guideline is to identify peak memory utilization for a given Web application, and assign that number plus 10 to the associated 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

Concepts

Additional performance and capacity planning factors (Office SharePoint Server)

Other Resources

SharePoint 2007 Test Data Population Tool (https://go.microsoft.com/fwlink/?LinkId=92678&clcid=0x409)