估计 PerformancePoint Services 的性能和容量要求
适用于： SharePoint Server 2010
上一次修改主题： 2017-01-18
本文介绍使用 PerformancePoint Services 对运行 Microsoft SharePoint Server 2010 的拓扑的影响。
备注
本文提供的特定容量和性能数字与实际环境中的数字有所不同，了解这一点非常重要。本文中的数字旨在为设计适当规模的环境提供一个着手点。在完成初始系统设计之后，应测试配置以确定系统是否支持环境中的各个因素。
本文内容：
测试服务器场特征
测试结果
建议
有关如何规划和运行 SharePoint Server 2010 容量计划的常规信息，请参阅Capacity management and sizing for SharePoint Server 2010。
测试服务器场特征
数据集
数据集由使用 SharePoint Server 2010 和 PerformancePoint Services 构建的包含一个中型仪表板的企业门户组成。仪表板包含链接到一个记分卡的两个筛选器、两个图表和一个网格。仪表板基于 SQL Server 2008 Analysis Services 多维数据集的 AdventureWorks 数据库示例使用的单个 Microsoft SQL Server 2008 Analysis Services (SSAS) 数据源。
下表说明仪表板上每个元素的类型和大小。
| 名称 | 说明 | 大小 |
|---|---|---|
筛选器 1 |
成员选择筛选器 |
7 个维度成员 |
筛选器 2 |
成员选择筛选器 |
20 个维度成员 |
记分卡 |
记分卡 |
15 个维度成员行 × 4 列（2 个 KPI） |
图表 1 |
折线图 |
3 个系列 × 12 列 |
图表 2 |
堆积条形图 |
37 个系列 × 3 列 |
网格 |
分析表格 |
5 行 × 3 列 |
中型仪表板使用“标题和两列”模板，并且仪表板项目大小设置为自动调整大小或仪表板的特定百分比。呈现仪表板上的每个项目时都使用介于 400 至 500 像素之间的随机高度和宽度，以模拟 Web 浏览器窗口大小的差异。必须更改每个仪表板项目的高度和宽度，因为将根据 Web 浏览器窗口大小呈现图表。
测试方案和过程
本节定义测试方案，并讨论每种方案使用的测试过程。下文中的测试结果一节提供了测试结果和特定参数等详细信息。
| 测试名称 | 测试说明 |
|---|---|
呈现仪表板并随机更改两个筛选器中的一个筛选器 5 次，两次交互之间暂停 15 秒。 |
|
呈现仪表板，选择图表，展开并折叠图表 5 次，两次交互之间暂停 15 秒。 |
|
呈现仪表板，选择网格，展开并折叠网格 5 次，两次交互之间暂停 15 秒。 |
|
使用了一个测试组合，它包含开始的测试的以下百分比。
| 测试名称 | 测试组合 |
|---|---|
呈现仪表板并随机更改两个筛选器中的一个筛选器 5 次。 |
80% |
呈现仪表板，选择图表，展开并折叠图表 5 次。 |
10% |
呈现仪表板，选择网格，展开并折叠网格 5 次。 |
10% |
Microsoft Visual Studio 2008 负载测试工具用于创建一组 Web 测试和负载测试，这些测试模拟用户随机更改筛选器并在网格和图表中导航。本文中使用的测试包含两次交互之间的正态分布的 15 秒暂停时间（也称为“思考时间”），以及两次测试迭代之间的 15 秒思考时间。应用了负载以产生 2 秒的用于呈现记分卡或报告的平均响应时间。平均响应时间是在初始 10 分钟预热时间后的 15 分钟内计算出的。
每次新的测试迭代都从由 5,000 个帐户组成的池中选择一个不同的用户帐户，并从由大约 2,200 个地址组成的池中选择一个随机 IP 地址（使用 Visual Studio IP 切换）。
测试组合对同一中型仪表板运行两次。在第一次运行中，数据源身份验证配置为使用无人参与服务帐户，这种情况下会使用一个共同帐户请求数据。数据结果对多个用户是相同的，并且 PerformancePoint Services 可以使用缓存来提高性能。在第二次运行中，数据源身份验证配置为使用每用户标识，并且 SQL Server Analysis Services 多维数据集配置为使用动态安全。在此配置中，PerformancePoint Services 使用用户的标识请求数据。由于数据结果可能不同，因此不能在用户之间共享缓存。在某些情况下，如果未配置 Analysis Services 动态安全并且为 Microsoft Windows 用户和组分配的 Analysis Services 角色相同，则可以共享每用户标识的缓存。
硬件设置和拓扑
实验室硬件
为了提供测试结果详细信息摘要，在测试中使用了几种服务器场配置。服务器场配置包括 1 到 3 台 Web 服务器、1 到 4 台应用程序服务器和一台运行 Microsoft SQL Server 2008 的数据库服务器。执行了 SharePoint Server 2010 的默认企业安装。
下表列出了用于测试的特定硬件。
| Web 服务器 | 应用程序服务器 | 运行 SQL Server 的计算机 | 运行 Analysis Services 的计算机 | |
|---|---|---|---|---|
处理器 |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
4px6c @ 2.4 GHz |
RAM |
16 GB |
32 GB |
16 GB |
64 GB |
操作系统 |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
NIC |
1 x 1 GB |
1 x 1 GB |
1 x 1 GB |
1 x 1 GB |
身份验证 |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
将服务器场扩展到包含多台 Web 服务器后，使用了硬件负载平衡器通过源地址相关性 在多台 Web 服务器之间平衡用户负载。源地址相关性记录传入请求的源 IP 地址以及将它们负载平衡到的服务主机，它将所有未来事务都传送给同一主机处理。
拓扑
起始拓扑包含两台物理服务器，一台服务器充当 Web 和应用程序服务器，另一台充当数据库服务器。此起始拓扑被认为是一个包含两台计算机 (2M) 的拓扑或“1×0×1”拓扑，其中会先列出专用 Web 服务器的数目，然后是专用应用程序服务器数，最后是数据库服务器数。
Web 服务器在下文中也称为 Web 前端 (WFE)。应用负载，直到遇到限制因素。通常，Web 或应用程序服务器上的 CPU 是限制因素，然后添加了资源以处理该限制。根据数据源身份验证配置（无人参与服务帐户或具有动态多维数据集安全设置的每用户标识），限制因素和拓扑会有很大差别。
测试结果
测试结果包含三个重要度量值，以帮助定义 PerformancePoint Services 容量。
| 度量值 | 说明 |
|---|---|
用户计数 |
Visual Studio 报告的总用户计数。 |
每秒请求数 (RPS) |
Visual Studio 报告的总 RPS，其中包括所有请求和静态文件请求，如图像和样式表。 |
每秒视图数 (VPS) |
PerformancePoint Services 可以呈现的视图总数。视图是 PerformancePoint Services 呈现的任何筛选器、记分卡、网格或图表，或者发送给呈现服务 URL 的包含 RenderWebPartContent 或 CreateReportHtml 的任何 Web 请求。若要了解有关 CreateReportHtml 和 RenderWebPartContent 的详细信息，请参阅 PerformancePoint Services RenderingService 协议规范（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x804)（该链接可能指向英文页面）。 可以为这些请求解析 IIS 日志，以帮助规划 PerformancePoint Services 的容量。此外，使用此度量值可以提供对仪表板组成部分的依赖性较小的数字。具有两个视图的仪表板可以与具有 10 个视图的仪表板进行比较。 |
提示
使用的数据源配置为使用无人参与服务帐户身份验证时，专用服务器的比率规则是每两台运行 PerformancePoint Services 的应用程序服务器对应一台 Web 服务器。
提示
使用的数据源配置为使用每用户身份验证时，专用服务器的比率规则是每 4 台或更多运行 PerformancePoint Services 的应用程序服务器对应一台 Web 服务器。
在应用程序服务器多于 4 台的拓扑中，瓶颈很可能是 Analysis Services 服务器。考虑监视 Analysis Services 服务器的 CPU 和查询时间，以确定是否应将 Analysis Services 扩展到多台服务器。Analysis Services 上查询时间的任何延迟都将显著增加 PerformancePoint Services 的平均响应时间，使其超出所需的阈值（2 秒）。
以下各表显示了从 2 台服务器扩展到 7 台服务器时无人参与服务帐户身份验证和每用户身份验证的测试结果摘要。包含其他性能计数器的详细结果在下文中提供。
无人参与服务帐户身份验证摘要
| 拓扑 (WFE x APP x SQL) | 用户 | 每秒请求数 (RPS) | 每秒视图数 (VPS) |
|---|---|---|---|
2M (1x0x1) |
360 |
83 |
50 |
3M (1x1x1) |
540 |
127 |
75 |
4M (1x2x1) |
840 |
196 |
117 |
5M (1x3x1) |
950 |
215 |
129 |
6M (2x3x1) |
1,250 |
292 |
175 |
7M (2x4x1) |
1,500 |
346 |
205 |
每用户身份验证摘要
| 拓扑 (WFE x APP x SQL) | 用户 | 每秒请求数 (RPS) | 每秒视图数 (VPS) |
|---|---|---|---|
2M (1x0x1) |
200 |
47 |
27 |
3M (1x1x1) |
240 |
56 |
33 |
4M (1x2x1) |
300 |
67 |
40 |
5M (1x3x1) |
325 |
74 |
44 |
2M 和 3M 拓扑
为了帮助说明每个事务的硬件成本和响应时间曲线，运行负载测试时使用了四个用户负载，这些用户负载不断增加以达到 2M 和 3M 拓扑的最大用户负载。
无人参与服务帐户身份验证
| 用户计数 | 50 | 150 | 250 | 360 |
|---|---|---|---|---|
平均 WFE/APP CPU |
19.20% |
57.70% |
94.00% |
96.70% |
RPS |
18 |
53 |
83 |
83 |
每秒视图数 |
10.73 |
31.72 |
49.27 |
49.67 |
平均响应时间（秒） |
0.12 |
0.15 |
0.38 |
2 |
.png "PPS_CapicityChart1")
每用户身份验证
| 用户计数 | 50 | 100 | 150 | 200 |
|---|---|---|---|---|
平均 WFE/APP CPU |
30.80% |
61.30% |
86.50% |
93.30% |
RPS |
17 |
32 |
43 |
47 |
每秒视图数 |
10.3 |
19.32 |
26.04 |
27.75 |
平均响应时间（秒） |
0.28 |
0.45 |
0.81 |
2 |
.png "PPS_CapicityChart2")
3M (1x1x1) 服务器场结果
无人参与服务帐户身份验证
| 用户计数 | 100 | 250 | 400 | 540 |
|---|---|---|---|---|
RPS |
36 |
87 |
124 |
127 |
每秒视图数 |
21 |
52 |
74 |
75 |
平均响应时间（秒） |
0.12 |
0.18 |
0.65 |
2 |
平均 WFE CPU |
11% |
28% |
43% |
46% |
SharePoint Server Internet Information Services (IIS) 工作组进程 W3WP 的最大 WFE 专用字节数。 |
0.7 GB |
1.4 GB |
2.0 GB |
2.4 GB |
平均 APP CPU |
25% |
62% |
94% |
95% |
PerformancePoint Services W3WP 的最大 APP 专用字节数 |
5.9 GB |
10.8 GB |
14.1 GB |
14.6 GB |
.png "PPS_CapicityChart3")
每用户身份验证
| 用户计数 | 50 | 120 | 180 | 240 |
|---|---|---|---|---|
RPS |
17 |
39 |
52 |
56 |
每秒视图数 |
10 |
23 |
31 |
33 |
平均响应时间（秒） |
0.28 |
0.48 |
0.91 |
2 |
平均 WFE CPU |
5% |
12% |
17% |
19% |
SharePoint Server W3WP 的最大 WFE 专用字节数 |
0.78 GB |
1.3 GB |
1.6 GB |
1.9 GB |
平均 APP CPU |
25% |
57% |
81% |
81% |
PerformancePoint Services W3WP 的最大 APP 专用字节数 |
19 GB |
20.1 GB |
20.5 GB |
20.9 GB |
.png "PPS_CapicityChart4")
4M+ 的无人参与服务帐户身份验证结果
从 4M 拓扑开始，应用了负载以产生 2 秒的用于呈现记分卡或报表的平均响应时间。接下来，添加了另一台服务器以处理限制因素（始终为 Web 服务器或应用程序服务器上的 CPU），然后重新运行了测试组合。重复此逻辑，直到总数达到 7 台服务器。
| 4M (1x2x1) | 5M (1x3x1) | 6M (2x3x1) | 7M (2x4x1) | |
|---|---|---|---|---|
用户计数 |
840 |
950 |
1,250 |
1,500 |
RPS |
196 |
216 |
292 |
346 |
每秒视图数 |
117 |
131 |
175 |
206 |
平均 WFE CPU |
77% |
63% |
54% |
73% |
SharePoint Server W3WP 的最大 WFE 专用字节数 |
2.1 GB |
1.7 GB |
2.1 GB |
2.0 GB |
平均 APP CPU |
83% |
94% |
88% |
80% |
PerformancePoint Services W3WP 的最大 APP 专用字节数 |
16 GB |
12 GB |
15 GB |
15 GB |
4M+ 的每用户身份验证结果
对配置为使用每用户身份验证的数据源重复同一测试。请注意，由于 Analysis Services 造成的查询延迟，添加应用程序服务器以创建包含 4 台应用程序服务器的拓扑不会增加 PerformancePoint Services 可以支持的用户数或每秒请求数。
| 3M (1x1x1) | 4M (1x2x1) | 5M (1x3x1) | 6M (1x4x1) | |
|---|---|---|---|---|
用户计数 |
240 |
300 |
325 |
325 |
RPS |
56 |
67 |
74 |
74 |
每秒视图数 |
33 |
40 |
44 |
45 |
平均 WFE CPU |
19% |
24% |
26% |
12% |
SharePoint Server W3WP 的最大 WFE 专用字节数 |
2.1 GB |
1.9 GB |
1.9 GB |
1.5 GB |
平均 APP CPU |
89% |
68% |
53% |
53% |
PerformancePoint Services W3WP 的最大 APP 专用字节数 |
20 GB |
20 GB |
20 GB |
20 GB |
Analysis Services CPU |
17% |
44% |
57% |
68% |
.png "PPS_CapicityChart5")
建议
硬件建议
测试表中的内存和处理器计数器应该用于确定安装 PerformancePoint Services 的硬件要求。对于 Web 服务器，PerformancePoint Services 使用建议的 SharePoint Server 2010 硬件要求。PerformancePoint Services 占用大量内存时，可能必须更改应用程序服务器的硬件要求。如果数据源配置为使用每用户身份验证，或者如果应用程序服务器运行的众多仪表板存在较长的数据源超时，则会发生这种情况。
数据库服务器在测试中没有成为瓶颈，并且在经过无人参与服务帐户身份验证的 7M 仪表板下最大 CPU 使用率为 31% 时达到峰值。PerformancePoint Services 内容定义（例如报表、记分卡和 KPI）存储在 SharePoint 列表中，并且由 PerformancePoint Services 缓存在内存中，以减少数据库服务器的负载。
内存占用情况
在某些配置中，PerformancePoint Services 可能会占用大量内存，因此监视 PerformancePoint Services 应用程序池的内存使用情况非常重要。PerformancePoint Services 在内存中缓存多个项目（包括 Analysis Services 和其他数据源查询结果），缓存时间等于数据源缓存生存期（默认为 10 分钟）。使用的数据源配置为使用无人参与服务帐户身份验证时，这些查询结果仅存储一次，并且在多个用户之间共享。但是，如果使用的数据源配置为使用每用户身份验证和 Analysis Services 动态多维数据集安全，则对每个用户每个视图（即“每个筛选器”组合）存储一次查询结果。
PerformancePoint Services 使用的基础缓存 API 是 ASP.NET 缓存 API。使用此 API 的主要优势是 ASP.NET 基于内存限制管理缓存和移除项目（也称为修剪）以防止出现内存不足错误。默认内存限制为物理内存的 60%。达到这些限制之后，PerformancePoint Services 仍然呈现视图，但在 ASP.NET 移除缓存条目的短暂时间内响应时间会显著增加。
承载 PerformancePoint Services 的应用程序池的性能计数器“ASP.NET 应用程序\缓存 API 修剪”可用于监视由于内存压力而出现的 ASP.NET 缓存修剪。如果此计数器大于零，请查看下表以找出可能的解决方案。
| 问题 | 解决方案 |
|---|---|
应用程序服务器处理器使用率较低，并且其他服务正在应用程序服务器上运行。 |
添加更多物理内存或限制 ASP.NET 缓存的内存。 |
应用程序服务器处理器使用率较低，并且只有 PerformancePoint Services 在应用程序服务器上运行。 |
如果可行，请配置 ASP.NET 缓存设置，以便缓存使用更多内存，或者添加更多内存。 |
应用程序服务器处理器使用率较高。 |
添加另一台应用程序服务器。 |
如果用户的 Analysis Services 角色成员身份集相同并且如果未配置动态多位数据集安全，则配置为使用每用户身份验证的数据源可以共享查询结果和缓存条目。这是 Microsoft SharePoint Server 2010 中的 PerformancePoint Services 的新功能。例如，如果用户 A 位于角色 1 和 2 中，用户 B 位于角色 1 和 2 中，用户 C 位于角色 1、2 和 3 中，则只有用户 A 和用户 B 可以共享缓存条目。如果配置了动态多维数据集安全，则用户 A 和 B 以及用户 C 都不能共享缓存条目。
Analysis Services
使用每用户身份验证测试 PerformancePoint Services 时，更改了两个 Analysis Services 属性以提高多用户吞吐量性能。下表显示了更改的属性以及每个属性的新值。
| Analysis Services属性 | 值 |
|---|---|
Memory \ HeapTypeForObjects |
0 |
Memory \ MemoryHeapType |
2 |
这两个内存设置将 Analysis Services 配置为使用 Windows 堆，而不是 Analysis Services 堆。更改这些属性之前以及增加用户负载时，响应时间会从 0.2 秒显著增加到 30 秒以上，而 Web、应用程序和 Analysis Services 服务器上的 CPU 使用率仍然很低。为了解决这一问题，使用 Analysis Services 动态管理视图 (DMV) 收集了查询时间，该视图显示单次查询时间从 10 毫秒增加到了 5000 毫秒。这些结果导致修改了上面的内存设置。
需要注意的是，尽管这样做会显著提高吞吐量，但是根据 Analysis Services 工作组的研究结果，更改这些设置会产生一定的单用户查询成本。
在更改任何 Analysis Services 属性之前，请参阅 SQL Server 2008 白皮书：Analysis Services 性能指南（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804)（该链接可能指向英文页面）以了解提高多用户吞吐量性能的最佳实践。
常见瓶颈及其原因
在性能测试过程中，揭示了一些常见瓶颈。瓶颈是指达到了服务器场特定组成部分的容量的情况。这会导致服务器场吞吐量停滞或下降。如果遇到处理器利用率很高这一瓶颈，可以添加其他服务器以消除该瓶颈。下表列出了一些常见瓶颈和可能的解决方案（假定处理器利用率很低，并且不是瓶颈）。
| 可能出现的瓶颈 | 原因和要监控的内容 | 解决方案 |
|---|---|---|
Analysis Services 内存堆性能 |
默认情况下，Analysis Services 使用它自己的内存堆而不是 Windows 堆，这会导致多用户吞吐量性能不佳。请使用动态管理视图 (DMV) 查看 Analysis Services 查询时间，以确定查询时间是否随用户负载增加并且 Analysis Services 处理器利用率很低。 |
将 Analysis Services 更改为使用 Windows 堆。有关说明，请参阅上文中的“Analysis Services”一节以及 SQL Server 2008 白皮书：Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804)。 |
Analysis Services 查询和处理线程 |
默认情况下，Analysis Services 会限制查询数和用于查询的处理线程数。长时间运行的查询和高用户负载可能会使用所有可用线程。可监视“MSAS 2008:线程”类别下的空闲线程和作业队列性能计数器。 |
增加可用于查询和处理的线程数。有关说明，请参阅 SQL Server 2008 白皮书：Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804) 的“Analysis Services”一节。 |
应用程序服务器内存 |
PerformancePoint Services 在内存中缓存 Analysis Services 和其他数据源查询结果，缓存时间等于数据源缓存生存期。这些项目可能会占用大量内存。可监视 PerformancePoint Services 应用程序池的“ASP.NET 应用程序\缓存 API 修剪”，以确定 ASP.NET 是否会因内存不足而强制执行缓存移除或修剪。 |
增加内存或增加默认 ASP.NET 缓存内存限制。有关其他讨论，请参阅上文中的“内存占用情况”一节。此外，还可参阅 ASP.NET 缓存元素设置（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x804)（该链接可能指向英文页面）以及 Thomas Marquardt 撰写的博客文章有关 ASP.NET 缓存内存限制的一些历史问题（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x804)（该链接可能指向英文页面）。 |
WCF 限制设置 |
PerformancePoint Services 作为 WCF 服务实现。WCF 会采取服务限制行为来限制最大并发调用数。尽管长时间运行的查询可能会遇到此瓶颈，但是这种瓶颈不常见。可监视 PerformancePoint Services 的 WCF/服务模型性能计数器未决调用，并与当前的最大并发调用数进行比较。 |
如果需要，请更改 Windows Communication Foundation (WCF) 限制行为。请参阅 WCF 服务限制行为 (https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x804) 以及 Wenlong Dong 撰写的博客文章 WCF 请求限制和服务器可伸缩性（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x804)（该链接可能指向英文页面）。 |
性能监视
可以使用性能计数器监视系统的运行状况，以帮助您确定什么时候必须强化或扩展系统。PerformancePoint Services 是 ASP.NET WCF 服务，可以使用用于监视其他任何 ASP.NET WCF 服务的同一性能计数器监视该服务。此外，使用下表中的信息可以确定要监视的补充性能计数器，以及应该应用性能计数器的进程。
| 性能计数器 | 计数器实例 | 注释 |
|---|---|---|
ASP.NET Applications / Cache API Trims |
PerformancePoint Services 应用程序池 |
如果值大于零，请查看“内存占用情况”。 |
MSAS 2008:Threads / Query pool idle threads |
暂缺 |
如果值为零，请查看 SQL Server 2008 白皮书：Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804) 中的“Analysis Services”一节。 |
MSAS 2008:Threads / Query pool job queue length |
暂缺 |
如果值大于零，请查看 SQL Server 2008 白皮书：Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804) 中的“Analysis Services”一节。 |
MSAS 2008:Threads / Processing pool idle threads |
暂缺 |
如果值大于零，请查看 SQL Server 2008 白皮书：Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804) 中的“Analysis Services”一节。 |
MSAS 2008:Threads / Processing pool job queue length |
暂缺 |
如果值大于零，请查看 Analysis Services 性能指南 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x804) 中的“Analysis Services”一节。 |
WCF CountersServiceModelService 3.0.0.0(*)\Calls Outstanding |
PerformancePoint Service 实例 |
如果值大于零，请参阅 WCF 请求限制和服务器可伸缩性（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x804)（该链接可能指向英文页面）。 |