估计 Windows SharePoint Services 协作环境的性能和容量要求 (Office SharePoint Server)
本文内容：
主要特征
测试环境
使用情况配置文件
建议
此性能和容量规划方案包含企业环境中用于协作和文档管理的单个 Windows SharePoint Services 3.0 服务器场。
主要特征
主要特征描述环境因素、使用情况特征和其他对于方案常见的注意事项。
此方案的主要特征包括：
身份验证/授权 — 通常，将通过使用安全组或基于其用户帐户为各个用户授予访问权限来对用户进行身份验证和保护网站和内容。此方案中使用的是集成 Windows 身份验证。
常见（读）和复杂（读/写）的用户操作 — 在协作环境中，用户将查看和编写内容。此方案的吞吐量目标旨在确保复杂的用户操作（例如上载或下载文档）的响应时间具有合理性。
随时间增长的数据和网站 — 除了估计初始数据量之外，Windows SharePoint Services 3.0 协作环境还必须允许数据和网站随时间增长。仅按初始数据量设计的服务器场容量很快就会超出限制。
用户响应时间 — 以位于Plan for software boundaries [Windows SharePoint Services] 部分结尾的用户响应时间表中列出的针对常见的、特殊的、长时间运行的和很少发生的操作的目标用户响应时间为目标。一些组织可能容许较慢的用户响应时间或可能要求较快的用户响应时间。预期的用户响应时间是决定总吞吐量目标的主要因素。（吞吐量定义为服务器场每秒可以处理的请求的数目）。大量用户要求更高的吞吐量目标以实现相同的用户响应时间。
用户并发 — 假定并发率为 10％，并且有 1％ 的并发用户在给定时间发出请求。换句话说，对于 10,000 个用户，则假定有 1,000 个用户同时使用解决方案，并且有 100 个用户将发出请求。
长时间运行的异步任务 — 诸如为内容建立索引和备份数据库之类的任务会将性能负载添加到服务器场。示例拓扑结构的一般性能特征假定这些任务将在非高峰期（例如夜间）运行。从而不会影响工作时间内的用户响应速率。
测试环境
测试此方案旨在帮助对不同的服务器场配置如何响应各种因素的更改进行估计，其中包括并发用户数、用户操作和对象（例如网站集、网站、库和列表）数目。
值得注意的是，虽然可以从测试结果中得到某些结论，但是本节中的特定容量和性能数据在现实环境中将发生变化。这些结果旨在为设计正确缩放的环境提供起始点。在完成初始系统设计之后，测试配置以确定系统是否支持环境中固有的因素。
有关测试部署的详细信息，请参阅Tools for performance and capacity planning (Windows SharePoint Services)。
假设
- 64 位体系结构 – 在测试环境中仅使用 64 位服务器。尽管 Windows SharePoint Services 3.0 可以部署在 32 位服务器上，但 Microsoft 建议您在 Windows SharePoint Services 3.0 服务器场部署中采用 64 位服务器。有关详细信息，请参阅文章About performance and capacity planning (Windows SharePoint Services) 中的 64 位与 32 位部分。
实验室拓扑结构
为了提供较好的测试结果详细信息，将使用几种服务器场配置进行测试，包括一台独立计算机以及八台带有运行 Microsoft SQL Server 2005 的单个和群集计算机的 Web 服务器。将模拟 32 到 256 个用户连接，使用八台客户端计算机进行测试。
下表列出用于测试的特定硬件。
| 计算机角色 | 硬件 |
|---|---|
Web 服务器 |
2 个双核 Intel Xeon 2.8 GHz 处理器 4 GB RAM |
数据库服务器 |
4 个双核 Intel Xeon 2.8 GHz 处理器 32 GB RAM |
客户端计算机 |
1 个 Pentium 3 1.2 GHz 处理器 1 GB RAM |
测试环境中使用了千兆（10 亿位/秒）网络。
使用情况配置文件
下表演示 Windows SharePoint Services 3.0 协作测试环境的使用情况配置文件。请注意，Windows SharePoint Services 3.0 协作方案的使用情况配置文件假定大多数用户操作是在工作组网站中执行的。
Windows SharePoint Services 中搜索的范围限定在网站集中。因此，搜索操作不会对吞吐量产生重大影响。
下表演示测试环境中列出的每类用户操作所使用的吞吐量的百分比。
| 操作 | 吞吐量百分比 |
|---|---|
获取主页 |
15.00 |
获取缓存的文档 |
15.00 |
获取静态文档 |
15.00 |
获取列表页 (HTML) |
10.00 |
获取列表页（网格） |
10.00 |
获取列表表单 |
7.00 |
404 错误 |
5.00 |
插入列表项 |
2.00 |
编辑列表项 |
2.00 |
删除列表项 |
2.00 |
插入文档 |
2.00 |
与 Outlook 同步 |
2.00 |
删除文档 |
2.00 |
列表 URL |
2.00 |
DAV（分布式创作和版本控制）打开文档以便进行编辑 |
1.00 |
DAV 保存文档 |
1.00 |
FPRPC（FrontPage 服务器扩展远程过程调用）打开文档以便进行编辑 |
1.00 |
FPRPC 保存文档 |
1.00 |
短期签出 |
1.00 |
传入电子邮件 |
1.00 |
RSS（真正简单的整合） |
1.00 |
启动工作流程 |
0.75 |
工作流程任务完成 |
0.75 |
添加/删除用户 |
0.50 |
建议
本节提供一般的性能和容量建议。根据这些建议可以确定在Plan for availability (Windows SharePoint Services) 一文中创建的初始拓扑结构的容量和性能特征，并可以确定是否需要扩大或缩小初始拓扑结构。
硬件建议
下表列出为 Web 服务器和数据库服务器建议的硬件。有关最低系统需求和建议的系统需求的详细信息，请参阅Determine hardware and software requirements (Windows SharePoint Services)。
备注
Web 服务器和数据库服务器的内存要求取决于服务器场的大小、并发用户的数量以及服务器场中功能和页的复杂性。下表中的内存建议可能适合于使用内存较少的服务器场，但应仔细监视内存使用情况以确定是否必须添加更多内存。
| 计算机角色 | 推荐使用的硬件 |
|---|---|
Web 服务器 |
双 2.5 GHz 或更快的处理器（推荐使用 3 GHz 或更快的处理器） 推荐至少使用 2 GB RAM 3 GB 可用磁盘空间 DVD 驱动器，可通过本地或网络访问 1024x768 或更高分辨率的监视器 |
数据库服务器 |
双 2.5 GHz 或更快的处理器（推荐使用 3 GHz 或更快的处理器） 推荐至少使用 4 GB RAM 内容与数据库容量的比例为 1:1.2，依此计算硬盘空间。也就是说，如果规划 100 GB 的内容，就需要至少 120 GB 的可用磁盘空间，加上用于事务日志的额外空间。 DVD 驱动器，可通过本地或网络访问 1024x768 或更高分辨率的监视器 |
起始点拓扑结构
可以通过将拓扑结构与Plan for availability (Windows SharePoint Services) 中提供的起始点拓扑结构进行比较来估计起始点拓扑结构的性能。这样做可以帮助您快速确定是否需要缩放起始点拓扑结构以达到性能和容量目标。
扩展拓扑结构的容量和性能
若要提高某一个起始点拓扑结构的容量和性能，则要么通过配置具有更大容量的服务器计算机来扩大，要么通过将额外的服务器添加到拓扑结构来扩展。本节描述几个扩展拓扑结构的一般性能特征。示例拓扑结构为缩放协作方案的拓扑结构提供了几种常用方式：
若要容纳更多的用户负载，请添加 Web 服务器计算机。
若要容纳更多的数据负载，请通过增加单台（群集或镜像）服务器的容量、通过升级为 64 位服务器或通过添加群集或镜像服务器来向数据库服务器角色添加容量。
保持比例不大于 8 台 Web 服务器计算机比 1 台（群集或镜像）数据库服务器计算机。
估计吞吐量目标
吞吐量是指服务器场每秒可以执行的操作的数量。在理想情况下，每秒请求的操作的数量低于给定性能级别的目标数量。如果请求的操作的数量超过目标数量，则将需要花费很长时间才能完成用户操作和其他操作。
按照每秒的请求数 (RPS) 计算吞吐量。通过使用典型的最终用户行为的模型，可以将 RPS 测量转换为用户总数。与许多人类行为一样，存在各种“典型”行为。Windows SharePoint Services 3.0 的用户模型具有以下两个变量：
“并发”- 积极使用系统的用户的百分比。
“请求速率”— 活动用户每小时生成的请求的平均数量。下表演示用户行为的四个级别。
可以按以下方式为典型负荷估计大致的吞吐量准则：
用户数量*活动用户的百分比/请求速率
例如，对于 1,000 个用户，将产生下面的值：
并发用户数 = 1,000 * 10% = 100
每用户每小时的估计请求数 = 36 = 每用户每 100 秒 1 个请求
吞吐量 = 并发用户数/请求速率 = 100/100 = 1 RPS
因此，一个 RPS 可以支持多达 1,000 个用户，每个用户每小时发出 36 个请求。
下表说明四个级别的用户负荷的吞吐量目标。
| 用户负荷 | 请求速率 | 支持的用户数 |
|---|---|---|
低强度 |
每小时 20 个请求。一个活动用户每 180 秒将生成一个请求。 |
对于每秒的每个响应，吞吐量支持 180 个并发用户，并总共支持 1,800 个用户。 |
典型强度 |
每小时 36 个请求。一个活动用户每 100 秒将生成一个请求。 |
对于每秒的每个响应，吞吐量支持 100 个并发用户，并总共支持 1,000 个用户。 |
高强度 |
每小时 60 个请求。一个活动用户每 60 秒将生成一个请求。 |
对于每秒的每个响应，吞吐量支持 60 个并发用户，并总共支持 600 个用户。 |
极高强度 |
每小时 120 个请求。一个活动用户每 30 秒将生成一个请求。 |
对于每秒的每个响应，吞吐量支持 30 个并发用户，并总共支持 300 个用户。 |
如果组织具有一个现有协作解决方案，则可以查看 IIS 日志以确定当前环境中的使用模式和趋势。有关分析 IIS 日志的详细信息，请参阅分析日志文件 (IIS 6.0)（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=78825&clcid=0x804)（该链接可能指向英文页面）。
如果组织正在规划新的协作解决方案部署，请使用下节中的信息来估计使用模式。
估计吞吐量目标
上一节所述的服务器场的估计吞吐量性能基于以下假设：
对于常见操作，用户响应速率小于 1 秒
用户并发率为 10％
在夜间 12 小时的时间范围中运行索引操作
使用本节中的信息可以更改这些假定的值以适合于组织的特征。结果可能是组织的不同吞吐量目标。
测试结果：根据服务器场配置计算出的吞吐量
本节中的表演示了各种用户操作配置文件的测试结果，这些结果是在使用本文前面的测试环境中列出的硬件的情况下得出的。用户连接的数量是测试过程中使用的一个固定参数。
下表演示针对读-写组合用户操作和只读用户操作的测试结果。
| 服务器场配置 | RPS | 总的用户连接数 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
低强度使用情况 |
典型强度使用情况 |
高强度使用情况 |
极高强度使用情况 |
||||
组合 |
读取 |
组合 |
读取 |
组合 |
读取 |
组合 |
读取 |
组合 |
读取 |
|
1 x 1 |
50 |
100 |
90,000 |
180,000 |
50,000 |
100,000 |
30,000 |
60,000 |
15,000 |
30,000 |
2 x 1 |
99 |
185 |
178,200 |
333,000 |
99,000 |
185,000 |
59,400 |
111,000 |
29,700 |
55,500 |
3 x 1 |
115 |
265 |
207,000 |
477,000 |
115,000 |
265,000 |
69,000 |
159,000 |
34,500 |
79,500 |
4 x 1 |
120 |
275 |
216,000 |
495,000 |
120,000 |
275,000 |
72,000 |
165,000 |
36,000 |
82,500 |
5 x 1 |
136 |
280 |
244,800 |
504,000 |
136,000 |
280,000 |
81,600 |
168,000 |
40,800 |
84,000 |
6 x 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
7 x 1 |
134 |
290 |
241,200 |
522,000 |
134,000 |
290,000 |
80,400 |
174,000 |
40,200 |
87,000 |
8 x 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
下图演示的是在前端 Web 服务器的数量发生更改时读-写操作和只读操作的吞吐量的变化。请注意，此图不是基于上表中的测试结果。它旨在说明在将前端 Web 服务器添加到系统时有关性能的常规趋势。
请注意，仅支持读取操作的系统（如静态门户网站）可以维护的吞吐量的级别比支持读取和写入操作的系统可以维护的吞吐量的级别更高。
.gif "Windows SharePoint Services 性能示例")
估计用户的响应时间
首先，确定组织是否可以容忍一个较慢的用户响应时间或是否要求一个更快的用户响应时间。按照以下方式对响应时间进行分类：
慢（3-5 秒） 用户响应时间可以降低到此速率，而不会出现任何问题。
建议（1-2 秒） 平均用户响应时间目标。
快（小于 1 秒） 对于要求业务速度的组织。
根据最符合组织要求的用户响应时间，确定基于用户数量的吞吐量目标。由于单个服务器部署可供多达 1,000 个用户使用，因此最少要列出 500 个用户。
下表列出基于用户响应时间的吞吐量目标。
| 总用户数 | 慢 (RPS) | 建议 (RPS) | 快 (RPS) |
|---|---|---|---|
500 |
0.4 |
0.5 |
0.7 |
1,000 |
0.7 |
1.0 |
1.2 |
5,000 |
4.0 |
5.0 |
6.0 |
10,000 |
9.0 |
10.0 |
12.0 |
20,000 |
18.0 |
20.0 |
24.0 |
50,000 |
40.0 |
50.0 |
60.0 |
100,000 |
90.0 |
100.0 |
120.0 |
在确定适合于组织的吞吐量目标之后，请重新评估示例拓扑结构的测试数据以验证选定的拓扑结构和硬件。
估计并发速率
紧接着，估计组织的并发速率。并发速率是指同时使用解决方案的用户的百分比。使用高峰期预期的并发速率。下表推荐基于用户总数和并发速率的吞吐量目标。
下表按照各种并发速率列出 RPS 中的吞吐量目标。
| 总用户数 | 5% 并发率 | 10% | 15% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|---|
500 |
0.25 |
0.5 |
0.75 |
1.25 |
2.5 |
3.75 |
5.0 |
1000 |
0.5 |
1.0 |
1.5 |
2.5 |
5.0 |
7.5 |
10.0 |
5,000 |
2.5 |
5.0 |
7.5 |
12.5 |
25.0 |
37.5 |
50.0 |
10,000 |
5.0 |
10.0 |
15.0 |
25.0 |
50.0 |
75.0 |
100.0 |
20,000 |
10.0 |
20.0 |
30.0 |
50.0 |
100.0 |
150.0 |
200.0 |
50,000 |
25.0 |
50.0 |
75.0 |
125.0 |
250.0 |
375.0 |
500.0 |
100,000 |
50.0 |
100.0 |
150.0 |
250.0 |
500.0 |
750.0 |
1,000 |
在基于预期并发速率确定适合于组织的吞吐量目标之后，请重新估计示例拓扑结构的测试数据以验证选定的拓扑结构和硬件。
估计索引窗口
最后，验证索引编制作业是否可以包含在 12 小时的夜间时段中。在 Windows SharePoint Services 3.0 协作环境中，索引编制作业通常表示不是由用户启动的运行时间最长的操作。必须在自己的环境中执行测试以确定索引编制作业的持续时间，以及索引编制作业占用的吞吐量是否干扰目标用户响应时间。
估计磁盘空间需求
本节提供可帮助您估计协作方案的磁盘空间需求的表。硬件的磁盘空间需求将根据服务器角色和方案的不同而不同，并取决于要存储在内容数据库中的数据、缓存需求和通过搜索进行爬网的外部内容。在下面的讨论中，可以根据可预测的磁盘空间需求（例如，安装文件的大小）将数字填入公式中。
首先，根据服务器角色来估计磁盘空间需求。然后，根据规划的拓扑结构，总计服务器角色将在其中共享同一物理服务器计算机的需求。最后，确保硬件具有适当的大小以满足磁盘空间需求。
此外，应将 SQL Server 存储的最佳方案应用于数据库服务器。有关详细信息，请参阅物理数据库存储设计（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x804)（该链接可能指向英文页面）。如果实施多个数据库服务器，则对于每个搜索服务器分别应用 SQL 磁盘空间系数。
备注
应从单独的驱动器或独立磁盘冗余阵列 (RAID) 上的数据文件中分别存储操作系统文件和程序文件。
数据库服务器磁盘空间需求
使用下表可以计算服务器场中的数据库服务器的磁盘空间需求。如果已实现多个数据库服务器，请分别为每个搜索服务器计算此类总和。
| 类别 | 描述 | 数量 |
|---|---|---|
操作系统文件 |
Windows Server 2003 安装程序和系统文件所需的磁盘空间。有关详细信息，请参阅选择安装分区的文件系统(https://go.microsoft.com/fwlink/?linkid=78866&clcid=0x804)。 |
4 GB |
交换文件 |
默认情况下，交换文件的大小将与物理内存的大小相同。 |
|
SQL Server 安装文件 |
SQL Server 安装程序和程序文件所需的磁盘空间。有关详细信息，请参阅 SQL Server 2005 Standard Edition 系统需求(https://go.microsoft.com/fwlink/?linkid=78870&clcid=0x804)。 |
425 MB |
数据库日志文件 |
日志文件的磁盘空间将基于日志设置和数据库数量发生变化。有关详细信息，请参阅物理数据库存储设计（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x804)（该链接可能指向英文页面）。 |
|
配置数据库 |
配置数据库将不会超过该大小。 |
1.5 GB |
内容数据库 |
估计内容数据库中将存储的初始内容量。请考虑以下因素：
|
|
未来增长 |
未来增长是协作方案的主要特征。所规划的量应为最初计划使用的数据量的两倍。输入一个适合于您的环境的数字。 |
|
可用空间 |
至少要为每个磁盘或卷留出 25% 的可用空间。 |
|
总计 |
搜索服务器磁盘空间需求
使用下表可以计算服务器场中搜索服务器的磁盘空间需求。如果已实现多个 Windows SharePoint Services 3.0 搜索服务器，请分别为每个搜索服务器计算此类总和。
| 类别 | 描述 | 数量 |
|---|---|---|
操作系统文件 |
Windows Server 2003 安装程序和系统文件所需的磁盘空间。有关详细信息，请参阅选择安装分区的文件系统(https://go.microsoft.com/fwlink/?linkid=78866&clcid=0x804)。 |
4 GB |
页面文件 |
默认情况下，页面文件的大小将与物理内存的大小相同。 |
|
Windows SharePoint Services 3.0 安装文件 |
此数字是一个基于完全安装的近似值。 |
1.3 GB |
Microsoft .NET Framework 3.0 版 |
60 MB |
|
内容索引 |
在内容数据库中添加内容的量，这些内容将通过索引服务器建立索引。将此量除以 2。生成的数字为内容索引的估计大小。 |
|
可用空间 |
至少要为每个磁盘或卷留出 25% 的可用空间。 |
|
总计 |
Web 服务器磁盘空间需求
使用下表可以计算服务器场中 Web 服务器的磁盘空间需求。
| 类别 | 描述 | 数量 |
|---|---|---|
操作系统文件 |
Windows Server 2003 安装程序和系统文件所需的磁盘空间。有关详细信息，请参阅选择安装分区的文件系统(https://go.microsoft.com/fwlink/?linkid=78866&clcid=0x804)。 |
4 GB |
交换文件 |
默认情况下，交换文件的大小将与物理内存的大小相同。 |
|
Windows SharePoint Services 3.0 安装文件 |
1.3 GB |
|
.NET Framework 3.0 版 |
60 MB |
|
可用空间 |
至少要为每个磁盘或卷留出 25% 的可用空间。 |
|
总计 |
性能监视
使用性能计数器来监视系统的运行状况是在确定何时需要扩展或扩充系统时的一个重要因素。使用下表中的信息可确定性能计数器监视哪些内容以及应对哪些进程应用性能计数器。
Web 服务器
下表演示服务器场中的性能计数器和要为 Web 服务器监视的进程。
| 性能计数器 | 应用于进程 | 注释 |
|---|---|---|
处理器占用时间百分比 |
总计 |
显示此线程占用处理器执行指令所用时间的百分比。 |
内存利用率百分比 |
应用程序池 |
显示应用程序池的系统内存平均使用率。必须标识要监视的正确应用程序池。 基本准则是确定高峰期的内存使用率，并将此数字加上 10% 之后再分配给应用程序池。 |
数据库服务器
下表演示服务器场中的性能计数器和要为数据库服务器监视的进程。
| 性能计数器 | 应用于进程 | 注释 |
|---|---|---|
处理器占用时间百分比 |
总计 |
显示此线程占用处理器执行指令所用时间的百分比。 |
内存利用率百分比 |
总计 |
显示系统内存的平均使用率。 |
下载此书籍
本主题包含在以下可下载书籍内，以方便您阅读和打印：
有关可下载书籍的完整列表，请参阅 Office SharePoint Server 2007 的可下载书籍。
另请参见
其他资源
Additional performance and capacity planning factors [Windows SharePoint Services]