估计 SharePoint Server 2010 中的 Access Services 的性能和容量要求
适用于： SharePoint Server 2010 Enterprise
上一次修改主题： 2016-11-30
本文提供有关使用 Microsoft SharePoint Server 2010 中的 Access Services 对运行 Microsoft SharePoint Server 2010 的拓扑的占用情况的指南。
本文内容：
测试服务器场特征
测试结果
建议
疑难解答
测试服务器场特征
本部分介绍在测试期间使用的数据集；在性能收集期间对产品产生的工作负荷；在测试期间使用的硬件；以及该硬件如何部署的拓扑。
数据集
Access Services 容量和性能高度依赖在服务上承载的应用程序的组成。表的大小和查询的复杂度通常对容量和性能的影响最大。测试使用具有代表性的大小和复杂度，但每个应用程序和数据集是不同的。容量和性能将取决于要使用的应用程序、其特定复杂度和数据大小。
为评估容量配置文件，在专用于 Access Services 的服务器场（未运行其他 SharePoint 测试）上模拟了 Access Services 应用程序。该服务器场包含以下代表性网站：
1,500 个 Access Services 应用程序，其配置文件大小为“小型”；每个列表最多有 100 个项目。
1,500 个 Access Services 应用程序，其配置文件大小为“中等”；每个列表最多有 2,000 个项目。
1,500 个 Access Services 应用程序，其配置文件大小为“大型”；每个列表最多有 10,000 个项目。
每个应用程序由多个列表组成，其他列表根据此最大的列表调整大小。Access Services 可处理多于 10,000 个项目的数据。选择此数目的“大型”配置文件是因为预计较大的应用程序不会很常见。
这些应用程序在以下应用程序间平均分布：
联系人 简单的联系人管理应用程序，由一个列表控制。
项目 简单的任务和项目跟踪应用程序，由两个列表（与每个项目关联的项目和任务）控制。
订单 简单订单输入系统，与 Microsoft Access 的 Northwind Traders 示例类似，但比例缩小了，而且包含许多相互关联的列表（订单、订单详细信息、发票、发票详细信息、采购订单、采购订单详细信息等）。
工作负荷
为模拟应用程序使用情况，创建了工作负荷以执行以下一项或多项操作：
打开表单
大致浏览表单
对数据表进行筛选和排序
更新、删除和插入记录
发布应用程序
呈现报告
每个工作负荷包含用户操作之间的“思考时间”，从 5 秒到 20 秒不等。这不同于其他 SharePoint 容量规则文档。Access Services 是具有状态的；在用户互操作之间保留了内存光标和记录集。应模拟完整的用户会话，而不仅仅是单个请求，这一点非常重要。对于单个用户工作负荷，平均每秒有两个请求。
下表显示用于确定要使用哪个应用程序和什么大小的应用程序的百分比。
| 小型 | 中等 | 大型 | |
|---|---|---|---|
联系人 |
16% |
10% |
9% |
项目 |
18% |
12% |
10% |
订单 |
11% |
8% |
6% |
绿色和红色区域定义
对于每个配置，运行了两个测试来确定“绿色区域”和“红色区域”。绿色区域是可承受的建议吞吐量。红色区域是短时间内可承受，但应避免的最大吞吐量。
绿色区域已定义为当运行的测试最多使用一半的瓶颈资源时的点。在这种情况下，瓶颈资源是以下三层之一的 CPU 百分比：前端 Web 服务器、应用程序服务器 (Access Data Services) 或数据库服务器 (SQL Server)。首先，瓶颈是针对特定配置确定的。如果瓶颈为 Access Data Services CPU，我们确保绿色区域测试对 Access Data Services 计算机使用的 CPU 范围介于 40% 到 50% 之间。
对于红色区域，选择了到达最大吞吐量的点。这证明 CPU 介于 80% 到 90% 之间。当搜索瓶颈时，我们查看 CPU 百分比、内存使用情况（私有字节）、磁盘队列长度、网络 I/O 和可能导致瓶颈的其他资源。
绿色和红色区域测试都以固定用户负荷运行了 1 小时。
您的结果可能会有所不同
本文中提供的特定容量和性能数字将与实际环境中的数字有所不同。此模拟只是实际用户可能执行的估计。所提供的这些数据旨在为设计相应比例的环境提供起点。在完成初始系统设计之后，应测试配置以确定系统是否支持环境中的各个因素。
硬件设置和拓扑
实验室硬件
为了提供测试结果详细信息摘要，在测试中使用了几种服务器场配置。服务器场配置包括一到四台前端 Web 服务器、一到四台应用程序服务器（如果存在 Access Services 或 Access Data Services）和运行 Microsoft SQL Server 2008 的单个数据库服务器计算机。此外，还使用四台客户端计算机来执行测试。所有服务器计算机都是 64 位的。所有客户端计算机都是 32 位的。
下表列出了用于测试的特定硬件。
| 计算机角色 | CPU | 内存 | 网络 | 磁盘 |
|---|---|---|---|---|
前端 Web 服务器 |
2 个处理器，4 核 2.33 GHz |
8 GB |
1 GB |
2 轴 RAID 5 |
应用程序服务器 (Access Data Services) |
2 个处理器，4 核 2.33 GHz |
8 GB |
1 GB |
2 轴 RAID 5 |
数据库服务器 (SQL Server) |
4 个处理器，4 核 2.6 GHz |
32GB |
1 GB |
直接附加存储 (DAS) 为每个逻辑单元号 (LUN) 附加 RAID 0 |
拓扑
根据我们的经验，应用程序服务器层（在其中运行 Access Data Services）上的 CPU 是吞吐量的一个重要限制因素。我们通过添加其他 Access Data Services 计算机来更改我们的拓扑，直到不再有瓶颈，然后添加前端 Web 服务器来获得更多吞吐量。
1x1： 一台前端 Web 服务器计算机对应一台 Access Data Services 计算机
1x2： 一台前端 Web 服务器计算机对应两台 Access Data Services 计算机
1x3： 一台前端 Web 服务器计算机对应三台 Access Data Services 计算机
1x4： 一台前端 Web 服务器计算机对应四台 Access Data Services 计算机
2x1： 两台前端 Web 服务器计算机对应一台 Access Data Services 计算机
2x2： 两台前端 Web 服务器计算机对应两台 Access Data Services 计算机
2x4： 两台前端 Web 服务器计算机对应四台 Access Data Services 计算机
运行 SQL Server 的计算机是相对较强的计算机，在任何时候都不会成为瓶颈（尽管在我们的 2x4 测试中，它开始接近 CPU 饱和），所以我们在拓扑中并未改变它。根据作为实际应用程序混合的一部分的查询，预计数据库服务器 (SQL Server) 层能够成为瓶颈。
对于我们的所有测试，Reporting Services 都在连接模式下运行，在应用程序服务器 (Access Data Services) 层运行。
测试结果
下表显示了 Access Services 的测试结果。对于每组测试，仅更改了某些特定变量以显示对服务器场性能的渐进影响。
本文中报告的所有测试在执行时都包含了思考时间或等待时间。这不同于 SharePoint 其他部分的容量规划结果。
有关 Access Services 的瓶颈的信息，请参阅本文后面的常见瓶颈及其原因（该链接可能指向英文页面）。
整体比例
下面的表和图总结了向服务器场添加其他前端 Web 服务器和专用 Access Data Services 计算机的影响。这些吞吐量数专门针对 Access Data Services 计算机，它们不反映对整体服务器场的影响。
| 拓扑 | 基线解决方案最大数 (RPS) | 推荐的基线 (RPS) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "最大和推荐 RPS")
推荐的结果
下图显示建议的可承受吞吐量的结果。
.gif "吞吐量与 ADS 的关系")
如本文前面所述，添加第 4 台 Access Data Services 计算机会将瓶颈变为前端 Web 服务器，添加第 2 台前端 Web 服务器会解除对前端 Web 服务器层的资源限制。这意味着，1x1、1x2 和 1x3 为合理配置。但是，当添加第 4 台 Access Data Services 计算机后，还应添加一个前端 Web 服务器。因为缩放是线性的（在 1x1 到 1x4 之间为直线），所以可假定添加第 7 台 Access Data Services 计算机还暗示着添加第 3 台前端 Web 服务器等，以满足服务器场的需求。
请记住，这些结果仅基于模拟的工作负荷，应监视实际部署以查找需要添加其他前端 Web 服务器来支持其他 Access Data Services 计算机的点。而且，前端 Web 服务器专用于 Access Services，而在现实中，前端 Web 服务器可能与其他 SharePoint 工作负载共享。下图显示结果。
.gif "响应时间与 ADS 的关系")
下图显示此吞吐量级别的响应时间。响应时间非常快，平均每个请求不到 ¼ 秒。
.gif "SQL CPU 利用率与 ADS 的关系")
这些结果显示 SQL Server 计算机不是瓶颈，因为添加第 2 台前端 Web 服务器解决了资源短缺的问题，并且 SQL Server CPU 始终小于 50%。但是，请注意，SQL Server 实例是与其他 SharePoint 服务和 SharePoint 本身共享的，因此累积影响可能会使 CPU 或磁盘 I/O 队列长度到达使它们成为瓶颈的点。
最大
下图显示结果，其中吞吐量超出可承受的范围。
在该图中，我们看到，再次需要第 2 台前端 Web 服务器来充分利用第 4 台 Access Data Services 计算机。再次提醒，您的结果可能会有所不同，因为这高度依赖应用程序及其使用方式。
.gif "吞吐量与 ADS 的关系")
在此情形下，由于整体系统受到压力，因此响应时间增加了。但是，这些水平仍大约为 1 秒，多数用户都可接受。
增加了 4 台 Access Data Services 计算机后，与 1 台前端 Web 服务器相比，2 台前端 Web 服务器增加了响应时间，这有些奇怪。这是因为 2 台前端 Web 服务器的系统的整体吞吐量增加了。
再次说明，SQL Server 在这里不是限制因素，因为添加第 2 台前端 Web 服务器会使我们在线性比例线上倒退。但是，在 SQL Server 实例上，我们几乎达到 90% 的 CPU 利用率。因此，只剩下极少量的上升空间。如果我们添加第 5 台 Access Data Services 计算机，则 SQL Server 计算机可能会成为瓶颈。
.gif "SQL CPU 利用率与 ADS 的关系")
详细结果
下面的表显示了推荐的配置的详细结果。
| 整体 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
请求数/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
测试数/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均延迟 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均前端 Web 服务器层 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
最大 w3wp 私有字节数 |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均应用程序服务器 (Access Data Services) 层 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
最大总私有字节数 |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
最大 w3wp 私有字节数 |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
最大 RS 私有字节数 |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| 数据库服务器 (SQL Server) 层（单个计算机） | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
平均私有字节数 |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
最大私有字节数 |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
平均磁盘队列总长度 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
下面的表显示最大配置的详细结果。
| 整体 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
请求数/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
测试数/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均延迟 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均前端 Web 服务器层 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
最大 w3wp 私有字节数 |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均应用程序服务器 (Access Data Services) 层 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
最大总私有字节数 |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
最大 w3wp 私有字节数 |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
最大 RS 私有字节数 |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| 数据库服务器 (SQL Server) 层（单个计算机） | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
CPU 百分比 |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
平均私有字节数 |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
最大私有字节数 |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
平均磁盘队列总长度 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
建议
本节提供一般的性能和容量建议。
Access Services 容量和性能高度依赖在服务上承载的应用程序的组成。表的大小和查询的复杂度通常影响最大。测试使用具有代表性的大小和复杂度，但每个应用程序和数据集是不同的。因此，容量和性能将取决于所使用的应用程序、其特定复杂度和数据大小。
硬件建议
Access Services 对前端 Web 服务器和应用程序服务器都使用标准硬件；不需要满足特殊要求。CPU 数、速度和内存的一般 SharePoint Server 2010 准则适用于应用程序服务器 (Access Data Services) 层中的计算机。
强化和扩展拓扑
若要增加起点拓扑之一的容量和性能，可执行以下两项操作之一。可通过增加现有服务器的容量来进行强化或通过向拓扑添加其他服务器来进行扩展。本节介绍多个扩展的拓扑的一般性能特征。
示例拓扑通过以下常见方式来扩展 Access Services 方案的拓扑：
若要提供更多用户负载，请检查现有 Access Services 应用程序服务器的 CPU。如果可能，请向这些服务器添加其他 CPU 和/或内核。根据需要添加更多 Access Services 服务器计算机。这可在前端 Web 服务器已成为瓶颈时进行，然后根据需要添加前端 Web 服务器。
在我们的测试中，前端 Web 服务器层和应用程序服务器 (Access Data Services) 层上的内存不是瓶颈。根据结果集的大小，内存可能会成为问题所在。但是，我们不希望那成为标准。跟踪 Access Data Services w3wp 进程的私有字节数，如此处所述。
在我们的测试中，SQL Server 不是瓶颈。但是，我们的测试是在与其他 SharePoint Server 2010 服务隔离的环境中进行的。应监视 SQL Server CPU 和磁盘 I/O，并根据需要添加其他服务器或心轴。
与性能相关的 Access Services 设置
控制 Access Services 的性能特征的方法之一是限制可执行的查询的大小和复杂度。Access Services 提供了一组可配置的限制来控制查询。以下每个查询都可通过 SharePoint 管理中心来设置。（在“应用程序管理”部分，单击“管理服务应用程序”，然后单击“Access Services”。）
通常情况下，必须从 SharePoint 中检索以执行查询的数据量对性能有显著影响。这可通过多种方式进行控制。首先，可限制查询的输入：
每个查询的最大源数
每个表的最大记录数
其次，可限制查询的生成大小：
每个查询的最大列数
每个查询的最大行数
允许外部联接
除查询的大小（数据输入和输出）外，还可控制数据的处理复杂度，以减少应用程序服务器 (Access Data Services) 层上的 CPU 负载：
每个查询的最大计算列数
每个查询的最大 Order By 子句数
显然，上述设置将影响可在服务器上运行的应用程序。例如，如果某应用程序在编写时具有查询的 40 个输出列，而这些设置低于此水平，则应用程序将引发运行时错误。必须在用户需求和可接受的性能之间实现平衡，这高度依赖预计在服务器场上运行的 Access 应用程序的类型。
可再采取一种更极端的措施。SharePoint Server 2010 在本地支持一组查询操作，Access Services 可扩充这些操作以涵盖一组更广泛的应用程序方案。为使 Access Services 改进从 SharePoint 进行的查询，可能必须从 SharePoint 内容数据库检索大量数据。相反，Access Services 可设置为只继续进行查询操作，SharePoint 可能在本地支持该操作。因此，避免更复杂的操作所需的数据提取：
- 允许非远程查询
优化
常见瓶颈及其原因
在性能测试过程中，揭示了一些不同的常见瓶颈。瓶颈是指达到了服务器场特定组成部分的容量的情况。这会导致服务器场吞吐量停滞或下降。
本文稍后的疑难解答中的表列出了一些常见瓶颈，并介绍其原因和可能的解决方案。
性能监视
可以使用性能计数器监视系统的运行状况，以帮助您确定何时必须强化或扩展系统。使用下表中的信息可以确定要监视的性能计数器，以及应该应用性能计数器的进程。
前端 Web 服务器
下表显示为服务器场中的 Web 服务器监视的性能计数器和进程。
| 性能计数器 | 适用对象 | 注释 |
|---|---|---|
% Processor Time |
Processor(_Total) |
显示此线程使用处理器来执行指令的时间所占的百分比。 |
私有字节数 |
Process(w3wp) |
此值不应接近为 w3wp 进程设置的最大私有字节数。如果它接近该值，则需要额外调查哪个组件正在使用内存。 |
Access Data Services
下表显示要为服务器场中的应用程序服务器（在本例中为 Access Data Services (Access Data Services)）监视的性能计数器和进程。
| 性能计数器 | 适用对象 | 注释 |
|---|---|---|
% Processor Time |
Processor(_Total) |
显示此线程使用处理器来执行指令的时间所占的百分比。 |
% Processor Time |
Process(w3wp) |
Access Data Services 在自己的 w2wp 进程中运行，并且可明显看出是哪个 w2wp 进程，因为它将获取批量 CPU 时间。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
由于需进行日志记录，等待过多磁盘写入。 |
% Processor Time |
Process(ReportingServicesService) |
报告由 SQL Server Reporting Services 处理。如果运行的报告过多，或如果报告非常复杂，则此进程的 CPU 和私有字节数将非常高。 |
私有字节数 |
Process(w3wp) |
Access Services 在内存中缓存查询的结果，直到用户的会话过期（其超时是可配置的）。如果正通过 Access Data Services 处理大量数据，则 Access Data Services 的 w3wp 的内存消耗将增加。 |
私有字节数 |
Process(ReportingSrevicesService) |
报告由 SQL Server Reporting Services 处理。如果运行的报告过多，或报告非常复杂，则此进程的 CPU 和私有字节数将非常高。 |
数据库服务器
下表显示为服务器场中的数据库服务器监视的性能计数器和进程。
| 性能计数器 | 适用对象 | 注释 |
|---|---|---|
% Processor Time |
Processor(_Total) |
显示此线程使用处理器来执行指令的时间所占的百分比。 |
% Processor Time |
Process(sqlservr) |
平均值大于 80% 表示数据库服务器上的处理器容量不足。 |
私有字节数 |
Process(sqlservr) |
显示正由 SQL Server 使用的平均内存大小。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
显示平均磁盘队列长度；等待提交给磁盘的数据库请求。这通常正是 SQL Server 实例负载过重的表现，也是添加额外磁盘心轴可能会帮助分散负载的表现。 |
疑难解答
下表列出一些常见的瓶颈，并且介绍了其原因和可能的解决方法。
| 瓶颈 | 原因 | 解决方法 |
|---|---|---|
Access Data Services CPU |
Access Services 取决于应用程序服务器层中的大量处理。如果使用 1x1、1x2 或 1x3 配置，则遇到的第一个瓶颈可能是 Access Data Services 服务器上的 CPU。 |
增加现有 Access Data Services 计算机中的 CPU 和/或内核的数量。如果可能，添加其他 Access Data Services 计算机。 |
Web 服务器 CPU 使用率 |
当用户请求导致 Web 服务器过载时，平均 CPU 使用率将接近 100%。这会导致 Web 服务器无法快速响应请求，并且可在客户端计算机上引发超时和错误消息。 |
此问题可通过两种方法之一解决。您可以向服务器场中添加更多 Web 服务器来分散用户负载，也可以通过添加更快的处理器来扩展 Web 服务器。 |
数据库服务器磁盘 I/O |
当硬盘的 I/O 请求数超过磁盘的 I/O 容量时，请求将排队。因此，完成每个请求的时间将增加。 |
跨多个物理驱动器分布数据文件可实现并行 I/O。博客 SharePoint 磁盘分配和磁盘 I/O（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x804)（该链接可能指向英文页面） 包含有关解决磁盘 I/O 问题的有用信息。 |
Reporting Services CPU 使用率 |
Reporting Services 进程占用了大部分 CPU 资源。 |
使某计算机专用于 Reporting Services，承载应用程序服务器 (Access Data Services) 层（连接模式）或前端 Web 服务器层（本地模式）的负载。 |