This section describes the performance and scalability limits of Windows SharePoint Services. The goal is to provide administrators with the information they need to purchase hardware, choose a server configuration, and manage the capacity of their Windows SharePoint Services deployment.

There are two kinds of limits in Windows SharePoint Services:

  • Throughput limits - The number of transactions per second that a given server configuration for Windows SharePoint Services can handle. This limit determines the number of users who can simultaneously use a given server resource.
  • Scale limits - The number of objects that can be created in a given scope (for example, the number of documents per folder). This limit determines the server configuration required to host a given number of objects.
Note:
The data presented here is based on Windows SharePoint Services version 2.0 performance testing. Performance variances with Windows SharePoint Services version 3.0 are slightly better. See Plan for performance and capacity for additional details.

More about the tested hardware and software

The following hardware was used to gather the performance and scalability data in Capacity Planning.

Web Servers

The Web server computers were Compaq DL360s with two 1 gigahertz (GHz) Pentium 3 processors and 1 gigabyte (GB) of memory. The computers were running a prerelease version of Microsoft Windows Server 2003, Enterprise Edition.

Note:
The single computer tests were run on Web server hardware.

Database Servers

The database server computers were Compaq DL380s with two 1 GHz Pentium 3 processors and 2 GB of memory. The computers were running Microsoft SQL Server 2000 SP 2 and a prerelease version of Windows Server 2003, Enterprise Edition.

Throughput Limits

The goal of the throughput testing is to measure the number of transactions per second that a server running Windows SharePoint Services can handle. The measured throughput is then used to extrapolate the number of simultaneous users by using a model of typical user behavior.

The Windows SharePoint Services team tests throughput by using automated load generation tools that work in machine time, not user time. In other words, real user behavior is not modeled in the test lab; rather, server capacity is measured using fictitious "super users" who issue requests as fast as the server can respond.

There are two main variables in the throughput testing:

  • Transaction mix - The mix of user transactions, such as "browse home page," "save document," and "edit list item."
  • Server configuration - The configuration, such as a single server or a server farm with two Web servers.

Transaction Mix

The transaction mix is the mix of different user operations seen by the server, such as "browse home page," "edit document," and so on.

The Windows SharePoint Services team tests two different transaction mixes:

  • Read/write - This is the typical Windows SharePoint Services site operation mix. Most of the load is browsing to pages and documents in the site, but there is a substantial amount of list and document authoring as well. For details on the read/write operation mix, see the table in the "More about the tested read/write transaction mix" section in this topic.
  • Read-only - This is the typical load of a reference site where the data on the server is changing very slowly. For this mix, the entire test load is on the home page of the site. The home page is one of the most expensive pages to render, so this is a fairly conservative read-only load.

The following table describes the mix of operations that make up the read/write transaction mix. The Windows SharePoint Services team counts only meaningful end-user operations in the throughput numbers, but the load on the server includes supporting transactions as well, such as getting the images, style sheets, and JavaScript files for the home page.

More about the tested read/write transaction mix

Table: Read/Write Transaction Operations Mix by Percentage

End-user operation Percentage

Get home page

9.0 percent

Get list page (HTML)

9.0 percent

Get list page (grid)

9.0 percent

Get list form

6.0 percent

Get static document

15.0 percent

Insert list item

1.5 percent

Edit list item

1.5 percent

Delete list item

1.5 percent

Insert document

1.5 percent

Open document for edit

1.5 percent

Save document

1.5 percent

Delete document

1.5 percent

List URLs

1.5 percent

Short term check-out

15.0 percent

Get cached document

15.0 percent

404 errors

10.0 percent

Note:
There are roughly two supporting transactions for each end-user transaction. In other words, the end-user operations make up about a third of the total transaction load on the server.

The server configuration describes how computers are configured to run the site. Windows SharePoint Services supports a server farm design where multiple Web servers can be used to serve the same content.

The solution tests the following configurations:

  • Light - Each user generates about two transactions per minute, on average, including supporting transactions. With this model, each transaction-per-second supports about 90 users.
  • Medium - Each user generates about four transactions per minute, on average. With this model, each transaction-per-second supports about 50 users.
  • Heavy - Each user generates about ten transactions per minute, on average. With this model, each transaction-per-second supports about 20 users.

The following two tables show the throughput results for each transaction mix, server configuration, and user model.

Table: Throughput Results for Read/Write Mix

Server configuration Transactions per second Heavy user count Medium user count Light user count

Single

49

980

2,450

4,410

1 by 1

69

1,380

3,450

6,210

2 by 1

121

2,420

6,050

10,890

3 by 1

136

2,720

6,800

12,240

4 by 1

140

2,800

7,000

12,600

5 by 1

140

2,800

7,000

12,600

6 by 1

140

2,800

7,000

12,600

7 by 1

140

2,800

7,000

12,600

8 by 1

140

2,800

7,000

12,600

Table: Throughput Results for Read-only

Server configuration Transactions per second Heavy user count Medium user count Light user count

Single

75

1,500

3,750

6,750

1 by 1

77

1,540

3,850

6,930

2 by 1

154

3,080

7,700

13,860

2 by 1

154

3,080

7,700

13,860

2 by 1

154

3,080

7,700

13,860

2 by 1

154

3,080

7,700

13,860

2 by 1

154

3,080

7,700

13,860

2 by 1

154

3,080

7,700

13,860

3 by 1

225

4,500

11,250

20,250

4 by 1

280

5,600

14,000

25,200

5 by 1

293

5,860

14,650

26,370

6 by 1

307

6,140

15,350

27,630

7 by 1

308

6,160

15,400

27,720

8 by 1

309

6,180

15,450

27,810

Adding Web servers to the server farm increases the capacity of the server farm, but only to a certain point:

  • For the read-only transaction mix, the capacity of the server farm increases steadily for up to four Web servers and stops increasing at six Web servers.
  • For the read/write transaction mix, the capacity does not increase beyond four Web servers because the throughput is now limited by the one database server computer. Extending capacity beyond this point requires adding another database server to the server farm.