Calculating the Number of Users a Server Can Support

Now that some of the most standard hardware configurations have been presented and discussed, the next question that needs to be answered is how many users can a SharePoint 2003 server support. To answer this question, the type of use the server or server farm will get needs to be better defined.

The Windows SharePoint Services 2.0 Administrator's Guide provides a definition of different levels of user activity and also provides information on the number of users who can be supported by different web servers and database server combinations.

Per the Windows SharePoint Services 2.0 Administrator's Guide, a general rule of thumb can be used:

• One transaction per second maps to 1,000 users. This rule of thumb is derived by applying the following model for user behavior:

  • 1,000 users at 10% peak concurrency

  • 100 simultaneous users (10% of 1,000)

  • 100 seconds per request per user (36 requests per hour per user)

  • 100 simultaneous users/100 seconds per user per transaction

  • One transaction/second

The user model for Windows SharePoint Services has two variables:

• Concurrency— The maximum percentage of the total user base who will be using the system simultaneously. The Windows SharePoint Services models all use 10% concurrency.

• Request rate— The number of requests per hour an active user generates on average. Windows SharePoint Services uses four models for user behavior:

  • Light— Twenty requests per hour. An active user generates a request every 180 seconds. Each response per second of throughput supports 180 simultaneous users and 1,800 total users.

  • Typical— Thirty-six requests per hour. An active user generates a request every 100 seconds. Each response per second of throughput supports 100 simultaneous users and 1,000 total users.

• Heavy— Sixty requests per hour. An active user generates a request every 60 seconds. Each response per second of throughput supports 60 simultaneous users and 600 total users.

• Extreme— One hundred-twenty requests per hour. An active user generates a request every 30 seconds. Each response per second of throughput supports 30 simultaneous users and 300 total users.

With these assumptions, Table 4.4 lists the number of users who can theoretically be supported by different server configurations. It is important to note that the data provided was generated by using automated load-generation tools, not actual users.

Table 4.4. Throughput Data

	Transactions per Second				Total User Count
	Light		Typical		Heavy		Extreme
	Request Rate		Request Rate		Request Rate		Request Rate
Configuration	Mix	Read	Mix	Read	Mix	Read	Mix	Read	Mix	Read
Single server	34	43	61,200	77,400	34,000	43,000	20,400	25,800	10,200	12,900
Single web server, single database server	65	70	117,000	126,000	65,000	70,000	39,000	42,000	19,500	21,000
Two web servers, one database server	121	132	217,800	237,600	121,000	132,000	72,600	79,200	36,300	39,600
Three web servers, one database server	156	194	280,800	349,200	156,000	194,000	93,600	116,400	46,800	58,200
Four web servers, one database server	161	256	289,800	460,800	161,000	256,000	96,600	153,600	48,300	76,800
Six web servers, one database server	157	278	282,600	500,400	157,000	278,000	94,200	166,800	47,100	83,400
Eight web servers, one database server	153	279	275,400	502,200	153,000	279,000	91,800	167,400	45,900	83,700
Eight web servers, two database servers		462		831,600		462,000		277,200		138,600

Figure 4.2 shows a graph of the transactions per second as they relate to the number of web servers and database servers. Information was not provided in the Windows SharePoint Services 2.0 Administration Guide for the number of transactions per second for the eight web servers by two database-servers configurations.

From Figure 4.2, it is clear that adding more than four web servers does not produce significant improvement. Adding a second database server dramatically improves the number of read transactions. Data was not provided for the results of a mixed read and write test of two databases.

The server hardware configuration used to come up with this data is

• Web servers— Compaq DL360s with two 1GHz Pentium 3 processors and 1GB of memory, running a prerelease version of Microsoft Windows Server 2003, Enterprise Edition, build 3718

• Database Servers— Compaq DL380s with two 1GHz Pentium 3 processors and 2GB of memory, running Microsoft SQL Server 2000 SP2 and a prerelease version of Windows Server 2003, Enterprise Edition, build 3718

A simplistic interpretation of this data suggests that a single system running Windows SharePoint Services with two slower processors and 1GB of memory can handle 10,200 extremely heavy users to 61,200 typical users performing read and write transactions. These numbers should be taken with a grain of salt, and testing should be performed on the specific SharePoint 2003 configuration in the organization's lab environment to determine whether the level of performance is acceptable to the user community. The automated tools used in this test probably didn't complain, whereas the user community certainly will. From a business standpoint, it makes sense to invest in more than a single server to support tens of thousands of users because if the single server crashes, there will be an overwhelming number of distressed users.

Note also that other variables will affect the performance of the SharePoint 2003 server or server farm including other traffic on the network, virus protection software, security software and encryption technologies in use, and type of load balancing solution in use.

Other Considerations in SharePoint Farm Sizing

An alternative way of looking at server sizing takes into account the impact of failures on the organization. For example, an organization of 10,000 users may need only one Windows SharePoint Services server if usage is limited to 100 employees, and the impact to these users is minimal if the server goes down. For example, they may be able to survive without access to their sites for one or two days while a new machine is brought online and their sites are restored from tape.

On the other hand, an organization with only 50 employees who use SharePoint Portal Server 2003 extensively not only for internal uses but also to collaborate with external clients and partners may suffer dire consequences if SharePoint is not available for more than a few minutes. Business could suffer, deadlines could be missed, and there could be financial consequences, or the reputation of the company could be hurt. In this case, a medium or even large server farm could be justified.

Due to the number of variables involved, most clients approach the server farm design challenge from the business angle and use a strategy of “growth as needed,” which justifies adding additional servers based on the levels of use and business impact of the SharePoint server farm.

Capacity and Scaling Limits for Windows SharePoint Services

Information provided in the Windows SharePoint Services 2.0 Administrator's Guide highlights additional capacity and scaling limits for Windows SharePoint Services, as listed in Table 4.5.

Table 4.5. Capacity and Scaling Limits for Windows SharePoint Services

Object	Scope	Limit	Comment
Site collection	Database	50,000	Total throughput degrades as the number of site collections increases.
Websites	Website	2,000	The interface for enumerating subsites of a given website does not perform well beyond 2,000 subsites.
Websites	Site collection	250,000	You can create a large total number of websites by nesting the subsites. For example, 100 sites, each with subsites, is 100,000 websites.
Documents	Folder	2,000	The interfaces for enumerating documents in a folder do not perform well beyond 1,000 entries.
Documents	Library	2 million	You can create large document libraries by nesting folders.
Security	Website	2,000	The size of the access control list is limited to
Principals			a few thousand security principals; in other words, users and groups in the website.
Users	Website	2 million	You can add millions of people to your website by using Microsoft Windows security groups to manage security instead of using individual users.
Items	List	2,000	The interface for enumerating list items does not perform well beyond a few thousand items.
Web Parts	Page	100	Pages with more than 100 Web Parts are slow to render.
Web Part	Page	10,000	Pages with more than a few thousand user
personalization			personalizations are slow to render.
Lists	Website	2,000	The interface for enumerating lists and libraries in a website does not perform well beyond a few thousand entries.
Document size	File	50MB	The file save performance degrades as the file size grows. The upper limit is about 50MB. This limit is enforced by the system, but the limit can be changed by the administrator.