估计 SharePoint Server 2010 中的 Microsoft Business Connectivity Services 的性能和容量要求

 

适用于: SharePoint Server 2010

上一次修改主题: 2016-11-30

**摘要:**本文提供了性能和规划指南,并讨论在 Microsoft SharePoint Server 2010 中使用 Business Connectivity Services 所产生的影响。

有关 Business Connectivity Services 的详细信息,请参阅Business Connectivity Services 概述 (SharePoint Server 2010)

本主题内容:

  • 术语表

  • 测试服务器场特征

  • 测试结果

  • 建议

术语表

下表定义了本文档中使用的 Business Connectivity Services 术语。

术语 定义

关联

关联可用于将相关的外部内容类型链接在一起。例如,可以将客户与其销售订单关联。关联可以与 Web 部件一起使用。

外部项目

外部内容类型的实例。

外部列表

外部内容类型的项目列表。

外部系统

可以由 Business Connectivity Services 建模的受支持的数据源,例如数据库、Web 服务或自定义 .NET Framework 程序集。

配置文件页

配置文件页面显示外部内容类型项目的数据。

Secure Store Service

一个共享服务,它可以安全地存储外部数据源的凭据集并将这些凭据集与个人标识或组标识相关联。

Web 部件

可重用 SharePoint 网站组件,用于呈现从多个数据源提取的信息。

测试服务器场特征

本节定义测试方案,并介绍为每种方案使用的测试过程。本文后面的测试结果部分提供了测试结果、特定参数等详细信息。

测试名称 测试说明

外部列表

  1. 呈现典型的外部列表。

  2. 通过更改外部列表的特征(项目数和项目大小等)来了解其对吞吐量和延迟的影响。

配置文件页

  1. 呈现典型的配置文件页。

  2. 通过更改配置文件页的特征(每个关联的项目数和项目大小等)来了解其对吞吐量和延迟的影响。

数据集

外部列表和配置文件页容量和性能很大程度上取决于数据的处理量。对于外部列表,数据的处理量是由以下三个变量决定的:外部列表中的项目数、每个项目的列数以及每个项目的大小。下表介绍了测试中使用的具有代表性的外部列表。

外部列表

项目数

500

2000

4000

每个项目的列数

25

25

25

项目大小

2 KB

4 KB

8 KB

对于配置文件页,数据的处理量取决于所用关联的数量和复杂性。关联可以将系统中相关的外部内容类型链接在一起。配置文件页可以提供多个关联,而每个关联又可以包含很多项目。下表介绍了测试中所用的具有代表性的配置文件页。

配置文件页

关联数

2

2

10

每个关联的项目数

100

500

2500

项目大小

4 KB

4 KB

4 KB

工作负荷

测试对配置文件页和外部列表上的吞吐量和延迟影响进行了度量。这些测试旨在帮助我们估计吞吐量和延迟如何对以下变量的更改做出响应:

  • 前端 Web 服务器的数量。

  • 外部列表的项目数。

  • 外部项目的大小。

  • 每个关联的项目数。

  • 身份验证方法(PassThrough 模式或 Secure Store Service 身份验证模式)。

  • 外部数据源(Windows Communication Foundation (WCF) Web 服务或 SQL Server 数据库)。

  • 按 CPU 使用率度量的前端 Web 服务器上的负载。

本文中所列的特定容量和性能数字与实际环境中的数字将会有所不同。所提供的数字旨在为设计适当规模的环境提供一个起点。在完成初始的系统设计之后,应测试配置以确定系统是否支持环境中的各个因素。

绿色和红色区域定义

对于每个配置,我们都运行了两项测试来确定绿色区域(即,可以维持的建议吞吐量)和红色区域(即,短时间内可以承受但应避免的最大吞吐量)。

为了确定红色区域和绿色区域的用户负载,我们首先进行了一个逐级测试,并在满足以下条件后停止测试:

  • 对于绿色区域,服务器场中所有前端 Web 服务器的 CPU 使用率稳定地维持在 40-50%。这是通过增加测试中使用的用户负载以及设立思考时间来实现的,这就意味着,每个测试可能会有不同的用户负载。

  • 对于红色区域,服务器场中所有前端 Web 服务器的 CPU 使用率稳定地维持在 90-99%。这是通过增加测试中使用的用户负载来实现的,这就意味着,每个测试可能会有不同的用户负载。

硬件、设置和拓扑

本部分介绍测试中使用的硬件、设置和拓扑。

实验硬件

为了获取高级别的测试结果详细信息,在测试中使用了若干种服务器场配置。服务器场配置包括 1 到 4 台 Web 服务器和一台运行 Microsoft SQL Server 2008 数据库软件的数据库服务器计算机。

下表列出了用于测试的特定硬件。

  前端 Web 服务器 应用程序服务器 数据库服务器 外部系统

处理器

2 个 2.33 GHz 处理器(4 核)

2 个 2.33 GHz 处理器(4 核)

4 个 3.2 GHz 处理器(4 核)

4 个 3.2 GHz 处理器(4 核)

RAM

8 GB

8 GB

32 GB

32 GB

操作系统

Windows Server 2008 R1 (x64)

Windows Server 2008 R1 (x64)

Windows Server 2008 R1 (x64)

Windows Server 2008 R1 (x64)

网络适配器数量

2

2

2

2

网络适配器速度

1 GB

1 GB

1 GB

1 GB

身份验证

NTLM

NTLM

NTLM

NTLM

软件版本

SharePoint Server 2010 预发行版

SharePoint Server 2010 预发行版

SQL Server 2008

SQL Server 2008

测试使用了两个外部系统:一个 WCF Web 服务和一个数据库。这两个外部系统承载在一台独立的物理计算机上(列出特定硬件的表中介绍了详细信息)。以下列表介绍了这两个外部系统:

  • WCF Web 服务   用于返回缓存的内存内数据的 WCF Web 服务。这些数据有效地存储在哈希表上,并且可以在 Business Connectivity Services 调用时立即返回。这些数据包含每种 .NET 类型的 25 个字段的 8000 多行。

  • Database   包含 25 列、不同数据类型和 8000 列的表。该表位于承载在 SQL Server 2008 上的独立数据库中。

拓扑

前端 Web 服务器上的 CPU 和内存是吞吐量的重要限制因素。在需要调用 Secure Store Service 的 Business Connectivity Services 身份验证模式中,还应考虑应用程序服务器上的 CPU。

在测试中拓扑是通过添加其他前端 Web 服务器来更改的。

Business Connectivity Services 容量规划拓扑

BCS 的容量规划拓扑

测试结果

以下部分显示了 SharePoint Server 2010 中的 Business Connectivity Services 测试结果。对于每组测试,仅更改了某些特定变量以显示对服务器场性能的渐进影响。

测试图使用以下图例来描述数据集:

外部系统、测试类型、[身份验证]、[关联数]、项目大小、项目数、CPU 负载

项目 说明

外部系统

外部数据源:WCF(WCF Web 服务)或 DB(数据库)。

测试类型

测试类型:EL(外部列表)或 PP(配置文件页)。

身份验证

身份验证方法:SSS(使用 Secure Store Service 身份验证模式,例如 WindowsCredentials)。如果未指定 SSS,测试期间使用 PassThrough 模式。

关联数

配置文件页中的关联数(例如,2A)。此项目只适用于配置文件页测试。

项目大小

项目大小(以 KB 为单位)。

项目数

外部列表中的项目数或每个关联的项目数。

CPU 负载

CPU 负载:RZ(红色区域)前端 Web 服务器 CPU 使用率超过 90% 或 GZ(绿色区域)前端 Web 服务器 CPU 使用率在 40% 到 50% 之间。

本文中报告的所有红色区域测试在执行时都没有思考时间(即,连续操作之间的自然延迟)。在实际环境中,在用户执行任务中的下一个步骤时,每个操作后面都有延迟。相比之下,在红色区域测试中,每个操作完成后立即执行下一个操作,这导致服务器场上存在连续负载。此负载引发了数据库争用及其他可对性能造成不利影响的因素。

前端 Web 服务器数量对延迟的影响

下图显示了前端 Web 服务器数量对延迟的影响的测试结果。这些测试结果分布在多个图中,目的是为了更方便比较相关变量。

图表 1:

下图显示了外部列表测试的结果。可以使用它来比较外部系统(数据库或 WCF Web 服务)和 CPU 负载(红色区域或绿色区域)对性能的影响。

图表 1:前端 Web 服务器数量对延迟的影响

Web 服务器数目对延迟的影响

以下列表描述了所用的数据集。

  • WCF,EL,4k,500,RZ:一个包含 500 个项目(每个项目包含 4 K 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,4k, 500,GZ:一个包含 500 个项目的外部列表(每个项目包含 4 K 数据),外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, EL, 4k,500, GZ:一个包含 500 个项目的外部列表(每个项目包含 4 K 数据),外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

图表 2:

下图显示了配置文件页测试的结果。可以使用它来比较外部系统(数据库或 WCF Web 服务)和 CPU 负载(红色区域或绿色区域)对性能的影响。

图表 2:前端 Web 服务器数量对延迟的影响

平均页面时间与 Web 服务器数目的关系

如图表 1 和图表 2 中所示,尽管添加了更多的前端 Web 服务器和用户,但绿色区域和红色区域方案中的平均页面时间几乎保持相同。(在测试期间,为了将所有前端 Web 服务器控制在必要的 CPU 活动范围,我们增加了用户负载)。不过,由于增加服务器场中前端 Web 服务器的数量可以让 SharePoint Server 在相同的速率下服务更多的用户,因此这样做仍然可以提高性能。与红色区域的情况相比,绿色区域的情况有明显(约 5 倍)的改进。因此,我们建议您将前端 Web 服务器 CPU 使用率控制在 40% 到 50% 的范围内。

以下列表描述了所使用的数据集:

  • WCF,PP,2A, 100,RZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB, PP,2A,100,RZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF, PP,2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, PP, 2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

图表 3:

下图显示了红色区域测试的结果。相同的数据是成对显示的,因此,仅有的变量是所使用的身份验证。这些数据可以用来确定使用 Secure Store Service 是否会影响性能。

备注

测试是在实验环境中执行的。使用 PassThrough 模式仅仅是为了进行比较。这些测试并没有暗示您应使用 PassThrough 模式来进行身份验证。

图表 3:前端 Web 服务器数量对延迟的影响

每秒请求数与 Web 服务器数目的关系

在红色区域方案中,从平均页面时间来度量,Secure Store Service 似乎并没有产生明显的开销。这是因为高用户负载这一影响更大的因素掩盖了 Secure Store Service 开销。在大多数情况下,Secure Store Service 和非 Secure Store Service 的结果是相同的。

您还应记住,Secure Store Service 对应用程序服务器的影响是最小的。

以下列表描述了所使用的数据集:

  • WCF,EL,4k,500,RZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,SSS,4k,500,RZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,2A,100,RZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且使用 PassThrough 身份验证模式,前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,SSS,2A,100,RZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB, EL, SSS,4k,500,RZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB, PP,2A,100,RZ:一个使用 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且使用 PassThrough 身份验证模式,前端 Web 服务器 CPU 使用率超过 90%。

图表 4:

下图显示了绿色区域测试的结果。相同的数据是成对显示的,因此,仅有的变量是所使用的身份验证。相同的数据集可以用来确定使用 Secure Store Service 是否会影响性能。

备注

测试是在实验环境中执行的。使用 PassThrough 模式仅仅是为了进行比较。这些测试并没有暗示您应使用 PassThrough 模式来进行身份验证。

图表 4:前端 Web 服务器数量对延迟的影响

平均页面时间与 Web 服务器数目的关系

在典型的负载方案中,与 Secure Store Service 相关的开销对于配置文件页会变得更明显。配置文件页的平均页面时间会多一点(约 20 微秒)。

以下列表描述了所使用的数据集:

  • WCF,EL,4k,500,GZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,EL,SSS,4k,500,GZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF, PP,2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,PP,SSS,2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,4k,500,GZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, EL, SSS,4k,500,GZ:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, PP,2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,PP,SSS,2A,100,GZ:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

前端 Web 服务器数量对吞吐量的影响

图表 1:

下图显示了按每秒请求数 (RPS) 度量的外部列表测试结果。可以使用它来比较 CPU 负载(红色区域或绿色区域)对性能的影响。

图表 1:前端 Web 服务器数量对吞吐量的影响

每秒请求数与 Web 服务器数目的关系

以下列表描述了所使用的数据集:

  • WCF,EL,4k,500,RZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,4k,500,GZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

图表 2:

下图显示了按每秒请求数 (RPS) 度量的配置文件页测试结果。可以使用它来比较外部系统(数据库或 WCF Web 服务)和 CPU 负载(红色区域或绿色区域)对性能的影响。

图表 2:前端 Web 服务器数量对吞吐量的影响

每秒请求数与 Web 服务器数目的关系

如图表 1 和图表 2 中所示,RPS 在添加第三台前端 Web 服务器之前以线性方式增加。添加第三台前端 Web 服务器之后,趋势变成了对数线性或次线性方式。尽管在服务器场中添加更多的前端 Web 服务器带来了一些好处,但这样做产生的价值还不及付出的成本。尤其是添加第四台前端 Web 服务器获得的好处就相当小了。

以下列表描述了所使用的数据集:

  • WCF,PP,2A, 100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB, PP,2A,100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,2A, 100,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, PP,2A,100,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

图表 3:

下图显示了按每秒请求数 (RPS) 度量的红色区域测试结果。相同的数据是成对显示的,因此,仅有的变量是所使用的身份验证。这些结果可以用来确定使用 Secure Store Service 是否会影响性能。

备注

我们的测试是在实验环境中执行的。使用 PassThrough 模式仅仅是为了进行比较。这些测试并没有暗示您应使用 PassThrough 模式来进行身份验证。

图表 3:前端 Web 服务器数量对吞吐量的影响

每秒请求数与 Web 服务器数目的关系

以下列表描述了所使用的数据集:

  • WCF,EL,4k,500,RZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,SSS,4k,500,RZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,2A,100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且使用 PassThrough 身份验证模式,前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,SSS,2A,100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,4k,500,RZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,SSS,4k,500,RZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB, PP,2A,100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,并且使用 PassThrough 身份验证模式,前端 Web 服务器 CPU 使用率超过 90%。

  • DB,PP,SSS,2A,100,RZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

图表 4:

下图显示了按每秒请求数 (RPS) 度量的绿色区域测试结果。相同的数据是成对显示的,因此,仅有的变量是所使用的身份验证。它可以用来确定使用 Secure Store Service 是否会影响性能。

备注

我们的测试是在实验环境中执行的。使用 PassThrough 模式仅仅是为了进行比较。这些测试并没有暗示您应使用 PassThrough 模式来进行身份验证。

图表 4:前端 Web 服务器数量对吞吐量的影响

每秒请求数与 Web 服务器数目的关系

如图表 3 和图表 4 所示,Secure Store Service 开销确实在某些情况下降低了 RPS 值。不过,对数线性趋势是相同的,并且在大多数情况下,Secure Store Service 和非 Secure Store Service 开销之间的 RPS 差异很小。

以下列表描述了所使用的数据集:

  • WCF,EL,4k,500,GZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,EL,SSS,4k,500,GZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,PP,2A,100,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,并且使用 PassThrough 身份验证模式,前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,PP,SSS,2A,100,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,4k,500,GZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB, EL, SSS,4k,500,GZ,RPS:一个包含 500 个项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,PP,2A,100,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,使用 PassThrough 身份验证模式,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,PP,SSS,2A,GZ,RPS:一个包含 2 个关联(每个关联包含 100 个项目)的配置文件页,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

项目大小对延迟的影响

下图显示了外部项目大小对延迟的影响测试结果。这些测试增加外部列表项目的大小,并度量它对延迟的影响。

项目大小对延迟的影响

平均页面时间与项目大小的关系

以下列表描述了所使用的数据集:

  • WCF,EL,500,RZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,而且前端 Web 服务器的 CPU 使用率超过 90%。

  • WCF,EL,SSS,500,RZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如 WindowsCredentials),而且前端 Web 服务器的 CPU 使用率超过 90%。

  • WCF,EL,500,GZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

  • WCF,EL,SSS,500,GZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如 WindowsCredentials),而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

项目大小对吞吐量的影响

下图显示了按每秒请求数 (RPS) 度量的外部项目大小对吞吐量的影响测试结果。这些测试增加外部列表项目的大小,并度量它对吞吐量的影响。

项目大小对吞吐量的影响

每秒请求数与项目大小的关系

随着项目大小的增加,RPS 性能始终会线性下降。高负载条件提供了更多 RPS。但是,从前面的测试结果来看,高负载条件还会延长页面响应时间。

以下列表描述了所使用的数据集:

  • WCF,EL,500,RZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,而且前端 Web 服务器的 CPU 使用率超过 90%。

  • WCF,EL,SSS,500,RZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如 WindowsCredentials),而且前端 Web 服务器的 CPU 使用率超过 90%。

  • WCF,EL,500,GZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

  • WCF,EL,SSS,500,GZ:一个外部列表,包含 500 个项目,外部系统是 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如 WindowsCredentials),而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

项目数对延迟的影响

下图显示了项目数对延迟的影响测试结果。这些测试增加外部列表项目的数量,并度量它对页面呈现时间的影响。

项目数对延迟的影响

平均页面时间与项目数目的关系

以下列表描述了所使用的数据集:

  • WCF,EL,4k,RZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,SSS,4k,RZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,4k,RZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,SSS,4k,RZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,4k,GZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,EL,SSS,4k,GZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,4k,GZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,SSS,4k,RZ:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

项目数对吞吐量的影响

下图显示了按每秒请求数 (RPS) 度量的项目数对吞吐量的影响测试结果。这些测试增加外部列表项目的数量,并度量它对吞吐量的影响。

项目数对吞吐量的影响

每秒请求数与项目数目的关系

如此图中所示,随着项目数的增加,RPS 几乎线性下降。与之前研究项目大小的影响的测试相比,增加项目数量似乎比增加项目大小对性能的影响更大。

以下列表描述了数据集:

  • WCF,EL,4k,RZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,SSS,4k,RZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,4k,RZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,EL,SSS,4k,RZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,EL,4k,GZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • WCF,EL,SSS,4k,GZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,4k,GZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

  • DB,EL,SSS,4k,GZ,RPS:一个包含可变数量项目(每个项目包含 4 KB 数据)的外部列表,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

每个关联的项目数对延迟的影响

下图显示了关联中的项目数对延迟的影响测试结果。这些测试增加关联中的项目的数量,并度量它对页面呈现时间的影响。

每个关联的项目数对延迟的影响

页面时间与每个关联的项目数目的关系

以下列表描述了数据集:

  • WCF,PP,2A,RZ:一个包含 2 个关联的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,SSS,2A,RZ:一个包含 2 个关联的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,PP,2A,GZ:一个包含 2 个关联的配置文件页,外部系统是一个数据库,而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

  • DB,PP,SSS,2A,GZ:一个包含 2 个关联的配置文件页,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

每个关联的项目数对吞吐量的影响

下图显示了按每秒请求数 (RPS) 度量的关联中的项目数对吞吐量的影响测试结果。这些测试增加关联中项目的数量,并度量它对吞吐量的影响。

每个关联的项目数对吞吐量的影响

请求数与每个关联的项目数目的关系

以下列表描述了数据集:

  • WCF,PP,2A,RZ:一个包含 2 个关联的配置文件页,外部系统是一个 WCF Web 服务,并且前端 Web 服务器 CPU 使用率超过 90%。

  • WCF,PP,SSS,2A,RZ:一个包含 2 个关联的配置文件页,外部系统是一个 WCF Web 服务,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率超过 90%。

  • DB,PP,2A,GZ:一个包含 2 个关联的配置文件页,外部系统是一个数据库,而且前端 Web 服务器的 CPU 使用率介于 40% 至 50% 之间。

  • DB,PP,SSS,2A,GZ:一个包含 2 个关联的配置文件页,外部系统是一个数据库,使用 Secure Store Service 身份验证模式(例如,WindowsCredentials),并且前端 Web 服务器 CPU 使用率介于 40% 到 50% 之间。

建议

本节提供一般的性能和容量建议。可使用这些建议来确定您创建的起始拓扑的容量和性能特性,以及决定是否必须向外扩展或向上扩展起始拓扑。

硬件建议

有关最低的和建议的系统要求的特定信息,请参阅硬件和软件要求 (SharePoint Server 2010) ()。

备注

Web 服务器和数据库服务器的内存要求取决于服务器场大小、并发用户数以及服务器场中的功能和页面的复杂性。对于小型的或使用较少的服务器场,使用下表中推荐的内存可能就足够了。但应仔细监控内存使用率以确定是否必须添加更多的内存。

Business Connectivity Services 性能方面的建议

本部分内容提供使用外部列表和配置文件页的性能建议以及 Business Connectivity Services 的常规性能建议。

外部列表建议

下表描述了数据从外部系统移动到外部列表中的方式。

负载 处理 呈现

Microsoft Business Connectivity Services 查询外部系统,并将返回的数据加载到 SharePoint Server 中。

对加载的数据应用任何其他处理(排序、筛选和分组)。

外部列表呈现页面上的项目。

Microsoft Business Connectivity Services 没有用于外部项目的内存内缓存。每次刷新外部列表时,都必须加载、处理和呈现数据。因此,这里的很多建议会要求您尝试限制必须处理的数据量。

以下列表提供了外部列表建议:

  • 通过限制从外部系统返回的行数,以便尽可能减少必须处理的项目数。这是影响外部列表性能的主要因素。我们建议您将返回的行数控制在 100 到 500。从外部系统返回的行数不应超过 2000。您可以使用筛选器限制外部系统返回的项目数。有关筛选器的详细信息,请参阅如何:基于 SQL Server 表创建外部内容类型 (https://go.microsoft.com/fwlink/?linkid=192184&clcid=0x804)。

  • 在前端 Web 服务器和应用程序服务器上呈现列表会占用大量 CPU。项目呈现数与加载和处理的项目总数是不同的。项目呈现数取决于外部列表视图的配置。应考虑总体用户体验以及可以在屏幕上轻松查看的项目数,将每页呈现的项目数保持为一个合理的数字。我们建议您将项目数控制在每页 30 个左右(这是默认值)。

  • 将外部列表中的列数保持为一个合理的数字。大量的列数会影响性能,并且还会产生不良的用户体验(屏幕上太多的列不便于查看)。

  • 不要在列视图中包含大型列(尤其是字符串)。在列视图中不应包含大于 1 KB 的列。外部内容类型仍然可以包含大型列。但是,只应在单个项目视图中显示大型列。

  • 设计外部列表时,将默认视图配置为大多数用户要查看的视图。更改视图上的排序或筛选需要加载、处理和呈现数据。

配置文件页建议

  • 关联数是影响配置文件页性能的主要因素。为了确保最佳性能,我们建议您尽可能将关联数配置为 2 个。

  • 每个关联的项目数越多,吞吐量和延迟性能方面的数字就会越差。

一般 Business Connectivity Services 建议

  • 从前端 Web 服务器数量对延迟的影响来看,绿色区域的情况与红色区域的情况相比明显会提高(约 5 倍)性能。我们建议您将前端 Web 服务器 CPU 使用率控制在 40% 到 50% 的范围内。

  • 项目数似乎比项目大小对性能的影响更大。如果您控制外部数据源,则可设置较高的项目大小,而将项目数控制在较低水平,以便获取更好的结果。例如,考虑将大的数据聚合到一个项目中,而不要将数据分布到很多项目中。

  • Microsoft Business Connectivity Services 的诊断日志记录级别也是影响延迟和吞吐量的重要因素,这一点用户应该已经认识到了。请将日志记录级别控制在能满足企业的常规使用需要的最低级别。只有在需要执行更密切的监视任务时,才可以将日志记录级别临时调整为较高的详细级别。

  • 外部系统的性能对 Business Connectivity Services 的性能也有很大的影响。请在规划容量和性能时考虑外部系统的延迟和吞吐量。

向上扩展和向外扩展拓扑

您可以通过将您的起始拓扑与规划可用性 (SharePoint Server 2010) (https://go.microsoft.com/fwlink/?linkid=189518&clcid=0x804) 上提供的起始拓扑进行比较,评估您的起始拓扑的性能。这样可以帮助您快速确定是否必须向上或向外扩展起始拓扑以满足性能和容量目标。

若要提高某个起始拓扑的容量和性能,可以通过增加现有服务器计算机的容量来进行向上扩展,也可以通过向拓扑中添加其他服务器来进行向外扩展。本部分介绍了多个向外扩展拓扑的常规性能特征。这些示例拓扑代表了以下用于向外扩展拓扑常用的方法。

  • 为了实现更多的用户负载,可以添加 Web 服务器计算机。

  • 为了实现更多的数据负载,可以通过以下方式为数据库服务器角色添加容量:增加一台(群集或镜像)服器务的容量,升级到 64 位服务器或添加群集或镜像服务器。

  • 将 Web 服务器计算机与(群集或镜像)数据库服务器计算机的比例控制在 8:1 或以下。尽管测试为每种测试方案得出了 Web 服务器与数据库服务器的最佳比例,但部署功能更强大的硬件,尤其是数据库服务器硬件,可能会在环境中产生更好的结果。

估计吞吐量目标

影响吞吐量的因素有很多。这些因素包括:

  • 用户数

  • 用户操作的类型、复杂性和频率

  • 操作中的回发数

  • 数据连接性能。

上述每个因素都会对服务器场吞吐量造成严重影响。在规划部署时,请仔细考虑这些因素。

可以采用多种方式部署和配置 SharePoint Server 2010。因此,没有简单的方法可以估计给定数量的服务器可以支持的用户数量。请确保在生产环境中部署 SharePoint Server 2010 之前,在您自己的环境中进行测试。

优化

常见瓶颈及其原因

在性能测试过程中,我们发现了一些常见瓶颈。瓶颈是指达到了服务器场某个组成部分的容量的情况。这会导致服务器场吞吐量出现平台期或下降。

下表列出了一些常见瓶颈并介绍了其原因和可能的解决方法。

性能和可伸缩性疑难解答

瓶颈 原因 解决方法

数据库争用(锁定)

数据库锁定可阻止多个用户对一组数据进行相互冲突的修改。当一组数据由一个用户或进程锁定时,其他用户或进程将无法更改该组数据,直到第一个用户或进程更改完数据并解除锁定。

为帮助减少数据库锁定的发生,可以执行以下操作:

  • 将提交表单分配给更多文档库。

  • 向上扩展数据库服务器。

  • 优化数据库服务器硬盘的读/写操作。

有一些方法可用来避开 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 服务器。有关详细信息,请参阅规划可用性 (SharePoint Server 2010) (https://go.microsoft.com/fwlink/?linkid=189518&clcid=0x804)。

性能监视

为了帮助您确定何时需要向上或向外扩展系统,您可以使用性能计数器来监视系统的运行状况。使用下表中的信息可以确定要监视的性能计数器,以及应该将性能计数器应用于的进程。

Web 服务器

下表显示了要为服务器场中的 Web 服务器监视的性能计数器和进程。

性能计数器 适用对象 注释

Processor time

全部

显示此线程使用处理器来执行指令的运行时间所占的百分比。

Memory utilization

应用程序池

显示应用程序池的系统内存的平均使用率。您必须确定要监视的正确的应用程序池。

基本准则是确定给定 Web 应用程序的内存使用率峰值,然后将该数加上 10 再分配给相关的应用程序池。

数据库服务器

下表显示了为服务器场中的数据库服务器监视的性能计数器和进程。

性能计数器 适用对象 注释

Average disk queue length

包含 SharedServices.mdf 的硬盘

每个心轴的平均值大于 1.5 表示该硬盘的写入时间不足。

Processor time

SQL Server 进程

平均值大于 80% 表示数据库服务器上的处理器容量不足。

Processor time

全部

显示此线程使用处理器来执行指令的运行时间所占的百分比。

Memory usage

全部

显示系统内存的平均使用率。

See Also

Other Resources

资源中心:SharePoint Server 2010 中的 Business Connectivity Services(该链接可能指向英文页面)