估计 SharePoint Server 2010 中的工作流性能和容量规划
适用于： SharePoint Server 2010
上一次修改主题： 2016-11-30
这篇性能和容量规划文章提供有关使用工作流对运行 Microsoft SharePoint Server 2010 的拓扑的影响的指南。
有关 SharePoint Server 2010 的容量规划的一般信息，请参阅性能和容量管理 (SharePoint Server 2010)。
目录
测试服务器场特征
测试结果
建议
疑难解答
测试服务器场特征
以下各节介绍测试服务器场的特征：
数据集
工作负荷
硬件、设置和拓扑
数据集
为获得基准，大多数测试都是在服务器场中单个网站集上的默认团队网站上运行的。手动启动测试通过使用包含 8,000 个项目的列表来启动工作流。
工作负荷
对此方案的测试可帮助推测不同的服务器场配置如何应对以下变量的更改：
前端服务器数量对跨多台计算机手动启动声明性工作流的吞吐量的影响
前端服务器数量对跨多台计算机自动对项目创建启动声明性工作流的吞吐量的影响
前端服务器数量对跨多台计算机完成任务的吞吐量的影响
本文中提供的特定容量和性能数字将与实际环境中的数字有所不同。所提供的数字旨在为设计适当规模的环境提供一个着手点。在完成初始系统设计之后，应测试配置以确定它是否支持环境中的各个因素。
本节定义测试方案，并讨论每种方案使用的测试过程。下文中的每个测试结果部分都提供了测试结果和特定参数等详细信息。
| 测试名称 | 测试说明 |
|---|---|
手动启动工作流的吞吐量 |
|
创建项时自动启动工作流的吞吐量 |
|
完成工作流任务的吞吐量 |
|
硬件、设置和拓扑
用于这些测试的拓扑对内容数据库使用单台计算机，并使用具有 SharePoint Server 2010 的默认安装的一至四台前端计算机。虽然这些测试中使用的工作流在 Microsoft SharePoint Foundation 2010 中不可用，但可以使用测试结果来推测这些部署上的类似方案。用于这些测试的数据集包含单个网站集，其中包含基于单个内容数据库上的团队网站模板的单个网站。
为了提供全面的测试结果细节，在测试中使用了多种服务器场配置。服务器场配置包括一至四台 Web 服务器和一台运行 Microsoft SQL Server 2008 的计算机。使用一台客户端计算机执行测试。数据库服务器和所有 Web 服务器都是 64 位，客户端计算机是 32 位。
下表列出了用于测试的特定硬件。
| Web 服务器 | 数据库服务器 | |
|---|---|---|
处理器 |
2px4c@2.33GHz |
4px4c@2.4GHz |
RAM |
4 GB |
16 GB |
操作系统 |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
存储 |
680 GB |
4.2 TB |
网络适配器数量 |
2 |
2 |
网络适配器速度 |
1 GB |
1 GB |
身份验证 |
NTLM |
NTLM |
软件版本 |
4747 |
SQL Server 2008 R1 |
SQL Server 实例数量 |
1 |
1 |
负载平衡器类型 |
无负载平衡器 |
无负载平衡器 |
ULS 日志记录级别 |
中等 |
中等 |
工作流容量规划拓扑
.gif "工作流规划拓扑")
测试结果
下表显示了 SharePoint Server 2010 中的工作流的测试结果。对于每组测试，仅更改了某些特定变量以显示对服务器场性能的渐进影响。
本文中报告的所有测试在执行时都没有思考时间（连续操作之间的自然延迟）。在实际环境中，在用户执行任务中的下一个步骤时，每个操作后面都有延迟。相比之下，在测试中，每个操作完成后立即执行下一个操作，这导致服务器场上存在连续负载。此负载可引发数据库争用及其他可对性能造成不利影响的因素。
扩展 Web 服务器对吞吐量的影响
以下吞吐量测试是使用 SharePoint Server 2010 附带的审批工作流运行的。工作流关联分配一项任务，并且所有实例都针对单个列表运行。此工作流的每个实例在内容数据库中创建以下内容：
工作流表中用于存储工作流状态的条目
五个辅助列表项（一个任务和四个历史记录项）
四个用于处理工作流的父项和任务上的事件的事件接收器
工作流延迟阈值设置得非常大，以便工作流操作从不会排队。每个测试运行五次，每次运行五分钟。
手动启动时的吞吐量
下表中的测试显示添加前端服务器如何影响通过 Web 服务同步启动工作流的吞吐量。此测试运行时的用户负载为：25 个并发用户连续对 Workflow.asmx 调用 StartWorkflow 方法，并且服务器场上没有任何其他负载。此用户负载是发生丢弃 Web 请求现象之前的最佳负载。列表预先填充了多达 8,000 项。
| 拓扑 | 审批工作流最大 RPS |
|---|---|
1x1 |
14.35 |
2x1 |
24.08 |
3x1 |
29.7 |
4x1 |
30.77 |
下图显示吞吐量的变化情况。添加前端服务器不一定以线性方式影响服务器场吞吐量，而是在前端服务器数量达到三至四个时，吞吐量达到最高点。总之，手动启动工作流的最大吞吐量是每秒 30 个工作流左右，并且添加四个以上的前端服务器可能不会产生多大影响。
手动启动时的吞吐量
.gif "手动启动时的吞吐量")
创建项时自动启动工作流的吞吐量
下表中的测试显示添加前端服务器如何影响创建项时自动启动工作流的吞吐量。此测试运行时的用户负载为：150 个并发用户连续调用列表 Web 服务来在单个列表中创建新列表项，并且服务器上没有任何其他操作。列表作为空列表启动。
| 拓扑 | 审批工作流最大 RPS |
|---|---|
1x1 |
13.0 |
2x1 |
25.11 |
3x1 |
32.11 |
4x1 |
32.18 |
下图显示吞吐量的变化情况。吞吐量非常接近手动启动操作的吞吐量。与手动启动测试类似，吞吐量在大约三个或四个前端服务器时达到最高点，最大值大约为每秒 32 个工作流。添加三个或四个以上的前端服务器不会产生多大影响。
自动启动工作流时的吞吐量
.gif "自动启动工作流时的吞吐量")
任务完成时的吞吐量
下表中的测试显示添加前端服务器如何影响完成工作流任务的吞吐量。上一个测试中的自动启动工作流使用的任务列表是用于完成任务的列表。此测试运行时的用户负载为：25 个并发用户连续对 Workflow.asmx 调用 AlterToDo 方法，并且服务器上没有任何其他操作。列表作为空列表启动。
| 拓扑 | 审批工作流最大 RPS |
|---|---|
1x1 |
13.5 |
2x1 |
23.86 |
3x1 |
27.06 |
4x1 |
27.14 |
下图显示吞吐量的变化情况。与手动启动测试类似，吞吐量在大约三个或四个前端服务器时达到最高点，最大值大约为每秒 32 个工作流。添加三个以上的前端服务器不会产生多大影响。
任务完成时的吞吐量
.gif "任务完成时的吞吐量")
列表大小和工作流实例数对吞吐量的影响
下表中的测试显示在列表大小和工作流数目增加时吞吐量如何变化。通过连续运行自动启动工作流测试来填充数据，直到列表中创建的项数达到 100 万个，同时在整个测试过程中的不同检查点处停止以测量吞吐量，就像执行核心吞吐量测试时一样。测试在 4x1 拓扑上执行。
为了在数据填充期间保持可靠性，必须启用工作流队列以避免达到数据库服务器上的最大连接数。如果没有可用连接，并且工作流操作无法连接到内容数据库，则操作将无法运行。有关工作流队列的详细信息，请参阅建议。
| 项或工作流数 | 基线解决方案最大数 (RPS) |
|---|---|
0 |
32.18 |
10 |
32 |
1,000 |
28.67 |
10,000 |
27.16 |
100,000 |
16.98 |
1,000,000 |
9.27 |
项和工作流数增加时的自动启动吞吐量
.gif "项目及工作流数目增加时的吞吐量")
对于单个列表及单个任务和历史记录列表，当项数目介于 1,000 到 100,000 之间时，吞吐量稳定降低。不过，在达到该数目之后，降低速度将会减小。我们将吞吐量降低归咎于多种因素。
一个因素是每个实例添加到内容数据库中的许多表的行数。如上所述，除了每个工作流实例注册的事件接收器外，工作流还创建多个列表项。当表大小在不同范围中增大时，添加行的速度会变得较慢，并且因添加这些行而造成的吞吐量的整体降低幅度比仅创建列表项时的降低幅度要大得多。
任务列表大小会产生其他开销。在将对新列表和新任务列表运行工作流的吞吐量进行比较时发现，任务列表对性能的影响更大。这是因为与父列表项相比，任务列表注册更多的事件接收器。下图说明了其中的区别。
| 使用不同列表配置时的吞吐量（每秒启动的工作流数） | 100 万项的任务列表 | 空任务列表 |
|---|---|---|
100 万项的列表 |
9.27 |
12 |
没有任何项的列表 |
9.3 |
13 |
如果您知道将必须对大型列表运行大量工作流，并且需要的吞吐量比测试时显示可获得的吞吐量更大，请考虑是否可以在工作流关联之间拆分任务列表。
建议
本节提供一般的性能和容量建议。可使用这些建议来确定您创建的起始拓扑的容量和性能特征，以决定是必须向外扩展还是向上扩展起始拓扑。
有关最低和推荐的系统要求的特定信息，请参阅硬件和软件要求 (SharePoint Server 2010)。
向外扩展拓扑
您可以通过向外扩展到最多四台 Web 服务器来提高工作流吞吐量。之后再添加的其他 Web 服务器将不会产生多大影响。工作流吞吐量可通过与性能相关的工作流设置加以限制。这些设置在工作流队列以及与性能相关的设置中详细介绍。
预测吞吐量目标
许多因素都会影响吞吐量。这些因素包括用户数以及用户操作的类型、复杂性和频率。对内容数据库执行许多操作或注册较多事件的较复杂的工作流将比其他工作流运行得更慢，并占用更多资源。
此测试中使用的工作流在内容数据库中创建多个内置到任务活动中的条目。如果您预期的工作流包含较少数量的任务，则可以预期会产生类似的吞吐量特征。如果大多数工作流包含非常轻型的操作，则吞吐量可能会提高。如果工作流将包含许多任务或密集的后端操作或处理能力，则可以预期吞吐量将会降低。
除了了解工作流将执行的操作外，还应考虑工作流将在哪里运行以及是否将对大型列表运行，如果是，则吞吐量将随着时间的推移而降低。
可以采用多种方式部署和配置 SharePoint Server 2010。所以，没有简单的方法可以估计给定数量的服务器可以支持的用户数量。因此，请确保在生产环境中部署 SharePoint Server 2010 之前，在您自己的环境中进行测试。
工作流队列以及与性能相关的设置
工作流使用队列系统来控制服务器场资源和内容数据库上与工作流相关的压力。通过使用此系统，当对数据库执行的工作流的数量达到管理员配置的阈值时，会将后续工作流操作添加到队列中并由工作流定时服务运行。默认情况下，此服务每分钟通过计时器作业接收一批工作流工作项。
多个与队列机制直接和间接相关的服务器场管理员设置会影响工作流的性能和扩展。以下各节介绍这些设置的作用以及如何调整它们来满足性能要求。
了解基本队列设置
服务器场管理员可以调整以下设置来配置队列系统的基本特征：
工作流延迟阈值 (Set-SPFarmConfig –WorkflowPostponeThreshold <integer>)
在其他请求和操作排队之前可对单个内容数据库执行的最大工作流数。已排队的工作流显示“正在启动”状态。这是服务器场范围的设置，默认值为 15。这表示每次处理的工作流操作数，而不是可以同时运行的最大工作流数。在工作流操作完成后，后续操作将能够运行。
工作流事件传送批次大小 (Set-SPWorkflow –BatchSize <integer>)
工作流定时服务是延迟阈值限制的一个例外，它将从队列中检索项批次并每次执行一个。这些批次可以大于延迟阈值。服务每次运行时接收的工作项数通过使用 BatchSize 属性设置。每个服务实例可以设置一次 BatchSize 属性。默认值为 100。在未配置为前端服务器的应用程序服务器上运行时，工作流定时服务要求在配置数据库中设置 Web.config 中的工作流配置设置。这必须通过对 SPWebApplication 对象调用 UpdateWorkflowConfigurationSettings() 的脚本来执行，该脚本将从前端服务器复制 Web.config 设置。
工作流计时器作业频率 (Set-SPTimerJob job-workflow –schedule <string>)
可以通过计时器作业设置来调整工作流定期服务运行的频率。默认情况下，该服务设置为每五分钟运行一次。这意味着在处理队列顶端的工作项之前会有五分钟的延迟。
备注
计划工作项（例如截止日期到期的任务）也通过相同的计时器机制进行选取。因此，它们将延迟相同的时间间隔。
可通过使用管理中心的共享服务管理禁用每台服务器上的工作流定时服务。默认情况下，该服务将在服务器场中的每台前端服务器上运行。每个作业都将在服务器场中的所有 Web 应用程序和内容数据库之间循环。
可结合使用延迟阈值、批次大小和计时器频率来限制对数据库执行的工作流操作。最大吞吐量将受操作排队速度和处理队列中的操作的速度影响。
例如，在使用默认设置、单个定期服务和单个内容数据库时，如果队列中有 1,000 项，则计时器作业将需要运行十次才能执行所有这些项，这将需要花费 50 分钟时间。不过，如果您将批次大小设置为 1,000 并将计时器作业设置为每分钟运行一次，则操作会在一分钟后全部开始执行。如果您将延迟阈值设置得较高，则会有更多操作同步运行，从而减少排队的请求数，并缩短处理这些工作流所需的总时间。
备注
建议将延迟阈值设置为不大于 200，因为并发工作流实例在它们自己的线程中运行，并且每个实例都将打开新的 SQL Server 连接，这样一来，在一段时间后，可能会达到数据库服务器上的最大连接数限制。
如果您不希望工作流在前端服务器上运行，并且知道操作不必立即执行，则可以隔离工作流定时服务使其在所选的应用程序服务器上运行，将延迟阈值设置为非常小的数以强制工作流通常在定时服务中运行，并设置较大的批次大小，以便它更快、更频繁地接收项。如果您希望确保工作流在整个系统中更同步地运行，请设置较大的延迟阈值，以便工作流不经常延迟并具有更即时的效果。
修改这些设置以针对所需的工作流运行方式进行优化。建议尝试不同的设置并进行测试，以针对您的环境和要求进行优化。
调整队列设置
如果在很长一段时间内服务器场都将承受沉重的工作流负载，或者系统中将有许多从工作流排队的延迟事件，那么排队的工作流操作数将会增加。除了基本队列设置外，您可能还必须调整以下设置以保持队列处于正常状态：
工作项事件传送批次大小
工作流用于排队事件的表是与 SharePoint Server 2010 中的其他非工作流功能共享的一般工作项表。因此，会有另一个计时器作业使非工作流工作项取消排队。与工作流事件传送批次大小类似，工作项事件传送批次大小指定每次取消排队的非工作流工作项数。
工作流故障转移计时器作业频率
在极少数情况下，如果无法将工作流事件传送给工作流实例，则会在队列中将事件传送安排为故障转移工作项以便稍后重试（5 分钟后启动，如果再次失败，则 10 分钟后启动，然后 20 分钟后启动，依此类推）。工作流故障转移计时器作业使故障转移工作项取消排队，并且此设置会调整故障转移计时器的运行频率。默认情况下，它每 15 分钟运行一次。
工作流故障转移批次大小
与工作流和工作项批次大小设置类似，此设置控制每个故障转移计时器作业将取消排队的故障转移事件数。
因为有许多计时器作业针对同一个表运行，所以大量排队项可导致数据库争用并降低吞吐量和可靠性。为减少争用，建议采取以下操作：
平衡延迟阈值和工作流批次大小，使批次大小足够小或计时器作业频率足够高，以便计时器作业可以在下一个计时器作业启动之前完成，从而避免累积太多无法完成的并行计时器作业。
为避免表锁定，不要将两个批次大小设置中的任一个设置为大于 5,000。
提示
错开工作流、工作项和故障转移计时器作业的频率，以避免它们总是同时执行。若要获得包含工作流的大型列表，将工作流计时器作业频率设置为四分钟，故障转移频率设置为六分钟，这样它们可以很好地在我们的数据填充脚本中运行。
改进任务和历史记录列表的扩展
工作流的每个实例都会生成许多任务和历史记录项。默认情况下，会对这些列表编制索引以帮助进行扩展，但随着这些列表的增大，性能将不断降低。为减小降低速度，应该对不同的工作流关联使用单独的历史记录和任务列表，并随着列表的变大在工作流关联设置中定期更改这些列表。
工作流还具有一项每日计时器作业 (job-workflow-autoclean)，它将自动删除已完成 60 天以上的工作流实例和实例的任务。启用此计时器作业可保持任务列表和任务列表上的事件尽可能干净。如果必须保留数据，请将数据写入其他列表或存档位置。此计时器作业不删除工作流历史记录项。如果您必须清除它们，则应使用脚本或通过列表用户界面手动执行清除。
其他注意事项
移除列表中的列会引发与列表中的项数相对应的数据库操作。移除工作流关联会从列表中移除工作流状态列。这会导致对大型列表执行大型操作。如果您知道列表具有数百万项，请将工作流设置为“没有新实例”而不是移除工作流。
疑难解答
| 瓶颈 | 原因 | 解决方法 |
|---|---|---|
数据库争用（锁定） |
数据库锁定可阻止多个用户对一组数据进行相互冲突的修改。当一组数据由一个用户或进程锁定时，其他用户或进程将无法更改该同一组数据，直到第一个用户或进程完成，更改数据并释放锁。 |
为帮助减少数据库锁定的发生，可以执行以下操作：
存在避开 SQL Server 2005 中的数据库锁定系统的方法，例如 NOLOCK 参数。不过，不建议也不支持使用此方法，因为它可能会损坏数据。 |
数据库服务器磁盘 I/O |
当传入硬盘的 I/O 请求数超过磁盘的 I/O 容量时，请求将排队。因此，完成每个请求的时间将增加。 |
跨多个物理驱动器分布数据文件可实现并行 I/O。博客 SharePoint 磁盘分配和磁盘 I/O（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x804)（该链接可能指向英文页面） 包含有关解决磁盘 I/O 问题的有用信息。 |
Web 服务器的 CPU 使用率 |
当用户请求导致 Web 服务器过载时，平均 CPU 使用率将接近 100%。这会导致 Web 服务器无法快速响应请求，并且可在客户端计算机上引发超时和错误消息。 |
此问题可通过两种方法之一解决。您可以向服务器场中添加 Web 服务器分散用户负载，也可以通过添加更快的处理器来扩展一个或多个 Web 服务器。 |
Web 服务器
下表显示为服务器场中的 Web 服务器监视的性能计数器和进程。
| 性能计数器 | 适用对象 | 注释 |
|---|---|---|
Processor time |
全部 |
显示此线程使用处理器来执行指令的时间所占的百分比。 |
Memory utilization |
应用程序池 |
显示应用程序池的系统内存的平均使用率。您必须确定要监视的正确应用程序池。 基本方针是确定给定 Web 应用程序的内存使用率峰值，然后将该数加上 10 分配给相关的应用程序池。 |
数据库服务器
下表显示为服务器场中的数据库服务器监视的性能计数器和进程。
| 性能计数器 | 适用对象 | 注释 |
|---|---|---|
Average disk queue length |
包含 SharedServices.mdf 的硬盘 |
每个心轴的平均值大于 1.5 表示该硬盘的写入时间不足。 |
Processor time |
SQL Server 进程 |
平均值大于 80% 表示数据库服务器上的处理器容量不足。 |
Processor time |
全部 |
显示此线程使用处理器来执行指令的时间所占的百分比。 |
Memory utilization |
全部 |
显示系统内存的平均使用率。 |