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:

Authentication, access control, and authorization Integrated Windows authentication is used in a portal collaboration scenario. Typically, sites and content are secured either by using security groups or by granting access to individual users based on their user account. The use of authentication and authorization impacts throughput, and requires a network connection between farm servers and domain controllers.

Associated directory This scenario includes an associated Active Directory directory service that provides user and organizational information. This information is used by Office SharePoint Server 2007 features to provide advanced functionality such as presence, targeting, and audiences.

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 Office SharePoint Server 2007 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 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 A concurrency rate of 10 percent is assumed, with 1 percent of concurrent users making requests at a given moment. For example, for 10,000 users, 1,000 users are actively using the solution simultaneously, and 100 users are actively making requests.

Long-running asynchronous tasks Tasks such as indexing content and backing up databases can affect server farm throughput. 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.

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 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 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.

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. Note that disk-based caching is not enabled by default. For information about enabling disk-based caching, see Disk-based Caching for Binary Large Objects (http://go.microsoft.com/fwlink/?LinkId=82617&clcid=0x409).

In order to provide a high level of test-result detail, several farm configurations were used for testing, ranging from one to eight Web servers with a single application server and a single database server computer running Microsoft SQL Server 2005 database software. Testing was performed with eight client computers simulating from 32 through 256 concurrent user connections. All server computers are 64-bit, and the client computers are 32-bit.

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

Application server

4 dual-core Intel Xeon 2.66 GHz processors

16GB 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. We recommend using a gigabit network between servers in a Office SharePoint Server farm to ensure adequate network bandwidth.

The following table shows the usage profile for the Office SharePoint Server 2007 collaboration test environment, and the percentage of throughput consumed by each listed type of user operation in the test environment.

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 need to scale the starting topology out or up.

Memory requirements for Web, application 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

Application 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

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.

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 if you need to 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 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 portal collaboration scenario:

To accommodate greater user load, add Web server computers. You can also add application servers to relieve some of the processing burden from the Web servers, particularly when specific application services such as Excel Calculation Services are being used heavily in your environment. The number of application servers you can deploy is principally limited by the capacity of the database server or servers to handle the additional I/O load.

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 one (clustered or mirrored) database server computer. While testing in our lab yielded an optimum ratio of 4x1x1 (4 Web front-end servers to 1 application server and one database server), deployment of more robust hardware, particularly for the database server, may yield better results in your environment.

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, including 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 impact on farm throughput. You should carefully consider each of these factors when you are planning 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, it is important that you conduct testing in your own environment before deploying Office SharePoint Server 2007 in a production environment.

If your organization has an existing collaboration 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) (http://go.microsoft.com/fwlink/?LinkId=78825&clcid=0x409).

If your organization is planning a new collaboration solution deployment, use the information in this section to estimate your usage patterns.

The table in this section shows test results for both read-only and read/write mix user operations using the hardware listed in Test environments earlier in this article. Note that for each farm configuration, a range of 1 to 8 Web servers was tested in conjunction with one application server and one database server. Therefore, a 3x1x1 farm configuration should be read as 3 (Web servers) by 1 (application server) by 1 (database server). Testing was not conducted on farms containing multiple application or database servers.

The following table shows test results for both read/write mix and read-only user operations.

Note:

Read/write mix testing was not conducted for farms larger than 6x1x1, as the limitations of the hardware used for testing were reached at a ratio of 4x1x1. Hardware with greater performance capabilities may be scalable beyond the tested limits shown here.

Farm size

RPS

Web server CPU

Database server CPU

Client computer CPU

Mix

Read

Mix

Read

Mix

Read

Mix

Read

1x1x1

49.8

73.3

91.00

98.40

17.90

15.00

10.89

6.50

2x1x1

79.2

141

76.40

93.10

24.50

29.40

14.04

11.10

3x1x1

106

208

71.23

90.75

42.00

54.20

19.10

15.00

4x1x1

128

248

67.55

82.58

66.70

80.20

23.34

18.00

5x1x1

116

278

47.96

70.46

73.70

93.40

26.60

20.00

6x1x1

95

284

32.87

53.62

72.10

96.10

19.16

21.00

7x1x1

n/a

284

n/a

42.19

n/a

96.40

n/a

21.00

8x1x1

n/a

224

n/a

33.34

n/a

76.90

n/a

17.00

The following graph shows changes in throughput for both read/write and read-only operations when the number of Web servers changes.

Note that systems that support only 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.

This section provides tables that can help you estimate disk space requirements for this 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 (for example, the size of installation files).

Additionally, best practices for SQL Server storage should be applied to database servers. For more information, see Physical Database Storage Design (http://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).

Disk space for log files will vary based on log settings and the number of databases. For more information, see Physical Database Storage Design (http://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:

Multiply the value of the size of initial content by 1.2 to get the value for the size of stored content in a SQL database.

If versioning is used for documents, a copy of each version is stored in the database.

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.

Use the following table to calculate disk space requirements for index servers and application servers in your farm. If more than one Office SharePoint Server 2007 index or application server is implemented, calculate this sum separately for each server.

To help you determine when you need to 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.