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.

Figure 4.2. Graph of transactions per second compared to server configuration.


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.

TIP

A number of testing tools are on the market, including Mercury LoadRunner or Microsoft's Application Center Test (ACT) tool, which can be used during the prototype testing phase or to periodically test the performance of the SharePoint environment. These tools are designed to use minimal hardware resources to emulate hundreds or thousands of concurrent users to put applications through the rigors of real-life user loads. Microsoft's ACT tool is specifically designed to stress test web servers and analyze performance and scalability problems with web applications, including Active Server Pages (ASP) and the components they use. Application Center Test supports several different authentication schemes and the SSL protocol, making it ideal for testing personalized and secure sites.


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.





Microsoft SharePoint 2003 Unleashed
Microsoft SharePoint 2003 Unleashed (2nd Edition) (Unleashed)
ISBN: 0672328038
EAN: 2147483647
Year: 2005
Pages: 288

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net