估计 Web 内容管理的容量和性能 (SharePoint Server 2013)
适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
企业通常使用 SharePoint Server 2013 发布匿名用户在 Internet 网站上访问的内容，或者通过身份验证的用户在 Intranet 网站上访问的内容。 本文包含容量和性能数据，用来帮助规划要使用的计算机数量、规划要求发布内容的计算机类型以及管理 SharePoint Server 2013 中的 Web 内容。
SharePoint 发布包括不同类型的发布网站以及每个网站可用的相关方法。 SharePoint Server 2013 的发布功能旨在帮助创建品牌 Internet、Intranet 和 Extranet 网站。 有关 SharePoint Server 2013 发布的详细信息，请参阅 SharePoint Server 中发布到 Internet、Intranet 和 Extranet 网站的概述。
简介
本文讨论了以下方案：
Internet 展示网站
向客户、合作伙伴、投资者和潜在员工提供信息。 此类网站允许匿名 Internet 用户查找有关公司的信息。 这些网站通常标有品牌，公司会严格控制其内容。
Internet 商务网站
推广公司向客户提供的产品和服务。 这些网站可以显示该公司提供的产品的目录。
Intranet 网站
公司在组织内部发布此网站。 这些网站向经过身份验证的用户共享信息，公司会严格管理此类网站以限制访问，也可以向所有内部用户开放。
Extranet 网站
向远程员工、合作伙伴和客户提供目标内容的访问权限。 这些网站可以提供使用创作内容的知识库的访问权限，内容会用元数据进行标记以对文章进行分类。 用户可以搜索或浏览特定信息，例如故障排除和支持文章。
跨网站集发布和内容搜索 Web 部件可以在这些方案中实现内容的跨网站集重用。 这些功能会影响您对容量的规划方式。 有关更多信息，请参阅 SharePoint Server 中的跨网站发布概述。
注意
跨网站集发布在本文中称为跨网站发布。
SharePoint Server 2013 中的托管导航为发布网站提供分类驱动导航。 有关详细信息，请参阅 SharePoint Server 中的托管导航概述。
本文中的容量和性能数据包含两个部分。 第一部分是新的跨网站发布方法和托管导航。 第二部分使用就地创作模型。
注意
本文中讨论的方案可以通过跨网站发布和就地创作网站实现。 跨网站发布和托管导航功能相互独立，可以分别使用。
在本文所使用的模型中，主要针对以下两个关键指标：
吞吐量
网站可承受的每秒页面访问数
服务器响应时间
服务器处理请求所需的时间，此时间会影响用户查看页面所需的时间。 本文中我们提供的服务器响应时间是 95% 和 50%。 这两个值意味着 95% 和 50% 的请求比所提供的值要快。 我们使用 SharePoint Usage 数据库中记录的给定请求的“Duration”来度量这些值。
内容新鲜度
更新项反映在搜索结果中所需的时间是使用跨网站发布方案时需考虑的指标。
本文中的方案使用以下两种状态：
绿色区域
服务器的利用率低于 60%。 这应该是大部分时间下服务器运行的目标。
红色区域
服务器接近完全利用。 这可以视为 SharePoint 网站所承受的负载比平常多的一种状态。 在红色区域中，服务器响应时间开始增加，因为服务器需尽力满足传入请求的需求。
先决条件信息
在阅读本文之前，请确保了解 SharePoint Server 2013 容量管理背后的关键概念。 下列文章将帮助您了解进行容量管理的建议方法，并提供了上下文信息以帮助您了解如何利用本文中的信息。
请注意，本文中不涉及影响发布方案功能的其他新功能。 这些方案包括设备渠道、SEO 优化、显示模板和查询规则。 此外，本文未详细介绍跨网站发布网站的功能和配置。 有关详细信息，请参阅 在 SharePoint Server 中规划跨网站发布 和 在 SharePoint Server 中配置 Web 内容管理解决方案。
有关容量和性能的详细信息以帮助了解本文中的数据，请参阅 SharePoint Server 2013 中的性能规划。
使用托管导航进行跨网站发布
本节提供我们针对以下两个领域的测试数据：针对匿名用户的跨网站发布和就地创作发布。
针对匿名用户的跨网站发布
本节中的测试结果基于基本跨网站发布网站模型以提供容量规划指导。 当您将 SharePoint 部署规划为允许匿名用户访问网站时，请使用此指导并相应调整您的部署规范。
在我们的测试中，测试用例使用跨网站发布功能。 此方案提供多个网站集的内容，这些网站集标记为目录，供 SharePoint Search Service 应用程序爬网。 使用搜索技术的 Web 部件（如内容搜索 Web 部件和目录项目重用 Web 部件）在其他网站的页面上显示内容。 有关更多信息，请参阅 SharePoint Server 中的跨网站发布概述。
我们在模型网站中使用以下旨在测试跨网站发布的特性：
具有大约 500 万个页面或项目的发布网站。
项目分为大约 1000 个类别。
内容位于其他网站集的一个或多个目录中。
网站使用链接到项目相关类别的托管导航。
对于此列表中稍后所述的基线部署拓扑，网站的平均每秒访问数为 80 次。 高峰期每秒页面访问数达到 100 次。 要增加吞吐量，增加拓扑中的计算机。 要减小吞吐量，移除拓扑中的计算机。
搜索爬网程序会进行连续爬网，间隔为 1 分钟，每秒更新目录五次。
网站具有以下页面和通信模式：
具有三个内容搜索 Web 部件和一个精简面板 Web 部件的主页（接收 15% 的通信）。
具有三个内容搜索 Web 部件、一个分类精简面板 Web 部件和一个精简面板 Web 部件的类别页，接收 45% 的通信。
具有目录项重用 Web 部件和两个内容搜索 Web 部件的目录项页，接收 40% 的通信。
每个内容搜索和目录项重用 Web 部件发出同步查询。
目录项页不使用匿名搜索结果缓存，因为它们仅接收一小部分通信。
服务器场对作为前端 Web 服务器运行的计算机启用二进制大型对象 (BLOB)。
我们用于测试此方案的服务器拓扑如下图所示：
图 1：测试实验室服务器拓扑
一台计算机托管 SQL Server，其中包含 SharePoint 使用的所有数据库
一台承载 SharePoint 服务应用程序、分布式缓存服务、搜索分析处理和搜索管理角色的计算机
一台承载搜索爬网程序和内容处理 (CPC) 角色的计算机
三台承载查询处理的搜索索引节点并充当前端 Web 服务器的计算机
注意
此测试中的计算机是运行 Windows Server 2008 R2 的物理计算机。 有关如何使用虚拟机和 Windows Server 2012 的建议，请参阅 SharePoint Server 2013 的搜索容量计划和容量规划。
重要
我们的测试实验室拓扑配置针对搜索驱动的发布方案进行了优化。 此配置不同于 SharePoint 部署的协作类型。 例如，我们的配置使用前端 Web 服务器作为搜索索引服务器来实现最佳性能。 > 在测试实验室拓扑中，我们了解到托管应用程序服务器的计算机未充分利用。 因此，我们将分布式缓存服务放在此应用程序服务器，而不是专用服务器上。 您可能决定在环境中的专用服务器上承载分布式缓存服务。 为实现最佳性能，我们建议您不要在具有搜索索引服务器角色的前端 Web 服务器上承载分布式缓存服务。
测试实验室报告
对于包含物理计算机的测试实验室，在 Visual Studio Team System (VSTS) 负载测试中，我们使用了图 1 中的拓扑。 有关详细信息，请参阅 Visual Studio Team System。 测试计算机的技术规范如下表所示。
注意
我们未使用浏览器缓存或相关请求，例如 VSTS 测试中的映像或 JavaScript 文件。 根据您自定义发布网站的方式，相关请求的数量可能会相差很大。 > 我们在测试中使用的页面在 1 (PLT1) 请求类型 (空浏览器缓存) 进行了近 50 个页面加载时间， (来自浏览器缓存) 结果的后续请求 (PLT2 请求类型大约 3 个请求。 SharePoint BLOB 缓存通常会满足对这些项目的请求，对性能指标没有太大影响。
| 服务器组件 | 运行 SharePoint Server 的服务器 |
|---|---|
| 处理器 | Intel Xeon CPU，2.33GHz（2 个处理器，共 8 个内核和 8 个线程） |
| RAM | 24 GB |
| 操作系统 | Windows Server 2008 R2 企业版 SP1,64 位 |
| SharePoint 驱动器的大小 | 200 GB 内部磁盘 |
| 用于搜索索引的存储容量 | 78 GB 外部磁盘阵列 (2 x Dell PERC H700 SCSI) |
| 网络适配器数量 | 2 |
| 网络适配器速度 | 1 GB |
| 身份验证 | 无 - 匿名 |
| 软件版本 | SharePoint Server 2013 |
| 服务器组件 | 数据库服务器 |
|---|---|
| 处理器 | Intel Xeon CPU L5520，2.27GHz（2 个处理器，共 8 个内核和 16 个线程） |
| RAM | 24 GB |
| 操作系统 | Windows Server 2008 R2 企业版 SP1,64 位 |
| 磁盘阵列 | 2 x Dell H700 SCSI |
| 网络适配器数量 | 2 |
| 网络适配器速度 | 1 GB |
| 身份验证 | NTLM |
| 软件版本 | Microsoft SQL Server 2008 R2 SP1 |
运行 10 分钟后的结果如下：
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户（模拟并发用户） 数： | 60 | 100 |
| 50% 服务器响应时间*： | 219 毫秒 | 302 毫秒 |
| 95% 服务器响应时间*： | 412 毫秒 | 635 毫秒 |
| 每秒页面访问数： | 78 | 98 |
这是一个显示搜索索引中的内容的跨网站发布方案。 现在我们看一下承载搜索查询的服务器所服务的查询数，以及匿名结果缓存所服务的查询数，这可能非常有趣。 在此模型中，匿名结果缓存可为 60% 的查询服务。 本文稍后将讨论匿名结果缓存。
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| 每秒总查询数： | 235 | 294 |
| 从匿名结果缓存提供服务的查询数： | 145 | 182 |
| 从搜索提供服务的查询数： | 90 | 112 |
运行测试时这些计算机的平均 CPU 和内存使用峰值如下：
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| 平均 CPU（每个前端 Web 服务器的搜索索引节点） | 59% | 80% |
| 平均 CPU（包括分布式缓存的应用程序服务器） | 8% | 9% |
| 平均 CPU（搜索 CPC 节点） | 5% | 5% |
| 平均 CPU (SQL Server) | 未测量 | 未测量 |
| 内存使用峰值（每个前端 Web 服务器的搜索索引节点） | 7.5 GB | 7.5 GB |
| 内存使用峰值（包括分布式缓存的应用程序服务器） | 10.1 GB | 10 GB |
| 内存使用峰值（搜索 CPC 节点） | 6.5 GB | 6.5 GB |
请注意，由于各个计时器作业在正常使用期间在服务器上运行，内存使用量可能会有所不同。 在进行两周负载恒定的测试运行后，我们发现索引/前端 Web 服务器节点使用 12 GB 内存。
搜索 Web 部件在跨网站发布页上如何显示内容
如果发布页包含一个搜索 Web 部件（如内容搜索 Web 部件），浏览器将开始处理页面，直到搜索查询完成。 这将改进页面的感知延迟。 搜索查询完成后，会将完整的查询结果发送到浏览器，并关闭与浏览器的连接。 用户可能会认为搜索结果是异步加载的。 但是，在请求页面时，查询仍从服务器发出。
请注意，内容搜索 Web 部件具有单独的异步模式，在加载页面后查询从浏览器发出。
负载变化对跨网站发布网站的影响
我们改变了在负载测试中使用的 VSTS 用户数（相当于访问网站的并发用户数）。 下图显示了随负载增加的服务器响应时间增加，每秒提供的页面数会逐步增加。 我们建议服务器响应时间应保持在 750 毫秒以下，以确保用户在 SharePoint 部署中获得响应快速的体验。
图 2：不同负载下的吞吐量和服务器响应时间图
向外扩展跨网站发布网站
如果希望 SharePoint 部署接收比上述基线案例更多或更少的通信，您可能需要更改服务器场上使用索引服务器和前端 Web 服务器角色运行的计算机数，以适应此通信。 下图显示了向外扩展同一跨网站发布网站的结果，该网站的负载模式不同，用作索引节点的前端 Web 服务器的计算机数也不同，范围从索引节点中具有前端 Web 服务器角色的一台计算机到六台：
图 3：向外扩展您的部署
在每种配置中，我们调整了负载，使服务器响应时间与上一节中的基线值相当。
请注意，随着计算机数量增加，拓扑的复杂度也开始超过好处。 每额外增加一台计算机，其吞吐量将小于环境中的现有吞吐量。 提供这些数字是为了显示横向扩展的模式。实际性能将根据 SharePoint 部署的构建方式而变化。
网站的规划准则
我们的大部分性能测试均使用前面各节中所述的部署。 下表中的准则旨在当您的部署与我们在测试实验室中所用部署不同时，帮助您做出正确的容量规划决策。
搜索索引中项目更多通常意味着延迟更长。 每个索引分区最多包含 1000 万个项目。 典型的网站很少需要显示超过 1000 万个项目。 因此在我们前面所述的拓扑中，它们只需要一个分区。 您可以使用更多索引分区来承载超过 1000 万个项目，或使用更多更小、更快的索引分区。 如果计划使用多个索引分区，请参阅 在 SharePoint Server 中缩放 Internet 网站的搜索 ，以正确调整搜索拓扑的大小。
每向页面（或页面布局）添加一个控制部件或 Web 部件，就会增加页面的服务器响应时间。
避免在一个页面上使用超过五个同步内容搜索 Web 部件或目录项重用 Web 部件。 在处理页面请求时，SharePoint Server 2013 会并行执行多达五个查询并返回结果。 如果页面上有五个以上的查询，SharePoint Server 2013 会在开始执行下一组五个查询之前执行前五个查询。 如果页面请求五个以上的内容搜索 Web 部件或目录项重用 Web 部件，您可以异步模式运行额外的内容搜索 Web 部件，或者使用查询原则和结果块。
内容搜索 Web 部件和目录项重用 Web 部件具有异步模式。 与 Web 部件相关的查询将在浏览器加载页面后执行。 对于缓慢查询，使用此模式，以便页面的其余部分更快地向用户显示。 否则，我们建议您使用同步查询，以获得最佳页面加载时间。
具有多个精简条件的精简面板 Web 部件会增加查询处理时间。 您可以更改为托管属性显示的精简条件数。 有关详细信息，请参阅 在 SharePoint Server 中配置精简条件和分面导航
如果您在具有导航节点深层次结构时使用分类精简面板 Web 部件，查询处理时间将会增加。 在具有 200 个以上导航节点的页面上，我们建议不要使用分类精简面板 Web 部件。 导航节点数过多会导致服务器响应时间延长并降低吞吐量。
如果您必须将 SharePoint 部署设计为具有高可用性，您必须添加以下项目：
一台可在现有计算机不可用时以分布式缓存角色在服务应用程序中运行的附加计算机
可在索引节点的前端 Web 服务器计算机不可用时承担负载的附加计算机
一台可以 CPC 角色运行的附加计算机，以确保在具有 CPC 角色的计算机不可用时网站仍可更新
SQL Server 拓扑，在其中一个数据库服务器不可用时继续为数据库查询提供服务
搜索爬网速度和内容新鲜度
在我们的测试中，我们还对已发布目录内容的更新过程进行了测试。 我们还记录了更新项出现在发布网站之前过去的时间。 在我们的实验中，我们每秒对目录更新五次，并将目录连续爬网设置为一分钟间隔。 我们发现更改出现在发布网站中的平均时间约为两分钟。 最短时间为接近一分钟，最长时间为三分钟。 我们发现在增加以 CPC 角色运行的计算机数时，这些数字没有很大变化。
但是，对于目录完全爬网，增加以 CPC 角色运行的计算机数会增加每秒处理的项目数。 下图显示了每秒处理的项目关系以及服务器场中具有 CPC 角色的计算机数。 请注意，此测试数据是从除在基线测试中使用的部署以外的 SharePoint 部署获取的。 结果应适用于 SharePoint 部署，因为增加更多 CPC 节点可增加完全爬网次数。
图 4：内容处理计算机 (CPC) 对完全爬网的影响
因此，如果您需要对目录更快进行完全爬网，您可以增加部署中使用 CPC 角色的计算机数。
Managed Metadata Service 应用程序的负载
我们的测试显示，涉及使用托管导航的网站的发布方案对 Managed Metadata Service 应用程序的内存或 CPU 要求不高。 对于我们前面所述的部署，Managed Metadata Service 应用程序可以在运行其他 SharePoint 服务应用程序的计算机上运行。 托管导航功能在收到对网站的第一个请求时与服务应用程序建立一个连接。 后续请求使用前端 Web 服务器缓存的值。 因此，前端 Web 服务器执行请求时，Managed Metadata Service 应用程序上没有负载。
匿名搜索结果缓存
匿名搜索结果缓存存储查询结果、查询的精简数据以及从 SharePoint 分布式缓存服务返回的额外结果表。 每个缓存项取决于查询参数，例如结果的排序顺序、请求的精简条件以及任何动态的重新排序规则。 缓存会影响 Web 应用程序处理的所有查询，包括来自搜索 Web 部件的查询和来自 CSOM 客户端的查询。 有关详细信息，请参阅 SharePoint Server 中的搜索体系结构概述 和 SharePoint Server 中对 Internet 网站的缩放搜索。
出于安全考虑，此缓存不用于经过身份验证的查询。
我们建议您将分布式缓存服务配置为仅在运行 SharePoint 服务应用程序的计算机上运行，以获得最佳结果。 分布式缓存服务不应在使用前端 Web 服务器角色的计算机上运行。
默认情况下，匿名搜索结果缓存每 15 分钟刷新一次项目。 可以使用 Microsoft PowerShell 在配置缓存的 Web 应用程序上配置缓存持续时间：
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
如果您希望搜索结果以比默认值更高的频率刷新，可减小此值。 请注意，这会增加搜索服务将需要服务的查询数。
我们建议您在接收大量通信的发布页上始终使用缓存。 此类页面包括使用搜索 Web 部件的网站主页和类别页。 我们建议不对目录项页使用缓存。 这是因为目录项页的访问频率比主页小得多，将项目存储在缓存中并不值得。
当我们在测试环境中关闭使用相同负载模式的异步搜索结果缓存时，服务器响应时间大大增加，以每秒页面访问数表示的吞吐量则下降。 下图显示了此关系：
图 5：匿名搜索结果缓存的影响
默认情况下，内容搜索 Web 部件配置为使用匿名搜索结果缓存。 在目录项页上使用的目录项重用 Web 部件则配置为不使用，这是因为这些页面通常使用稀疏访问模式。
若要将单个 Web 部件的缓存行为配置为使用 (或不) 匿名搜索结果缓存，请在 Web 部件的 属性中 DataProviderJSON 设置子属性“TryCache”的值。 如果值为“true”，则查询将使用缓存。 如果值为“false”，则查询不使用匿名搜索查询的缓存。
输出缓存的效果
输出缓存是在发布方案中减少 SharePoint Server 2013 上的负载的有效方法。 有关输出缓存工作原理的更多详细信息，请参阅 输出缓存和缓存配置文件。
SharePoint 部署可能从输出缓存中受益，可减少 SharePoint 内容数据库和 Search Service 应用程序的负载。 下面是一些示例情况：
您在某些页面上收到大量通信。
您在 SharePoint 内容数据库上收到大量通信。
为搜索查询提供服务的计算机在高 CPU 利用率下运行。
建议对网站上非常受欢迎的页面（例如网站的主页或顶级类别页面以及接收大量流量的某些项目页面）使用输出缓存。
重要
SharePoint Server 2013 中存在一个已知问题，即启用了输出缓存的页面也包含内容搜索 Web 部件。 若要避免部署中出现此问题，请安装 SharePoint Server 2013 更新：2013 年 3 月 12 日。
下图显示了在主页和接收 60% 网站通信的类别页上使用输出缓存的测试环境中的部分结果。
图 6：输出缓存对主页和类别页的影响
注意
内容搜索 Web 部件具有在异步模式下运行的设置。 输出缓存不适用于来自异步内容搜索 Web 部件的负载。
使用率分析处理
若要使有关使用情况分析的信息可供使用，SharePoint Server 2013 将处理使用情况数据库中的信息。 在我们的拓扑中，将在包含搜索管理节点、分布式缓存服务和其他服务应用程序的节点上执行分析处理。 有关详细信息，请参阅 SharePoint Server 中的分析处理概述
我们使用在前面测试中使用的跨网站发布网站测量了分析处理时间。 我们测量了 SharePoint Server 2013 处理网站页面中大量点击事件所需的时间。 这些结果来自跨网站发布网站，但也适用于使用就地创作发布方法的网站。
对于围绕使用率分析处理的测试，我们每天生成以下模拟事件，为期一周：
在 300 万个列表项和 400,000 名用户之间发生了 2750 万次点击事件。
我们使用了 Zipf 分发，因此有些列表项和用户具有很多事件，其他列表项和用户的事件则较少。
这样每天总共生成 750 万个事件，模拟为网站生成不同通信模式的不同用户。
我们触发分析运行七次，以模拟一周的通信。 我们每天对前六天积聚的数据运行使用率分析作业。 然后我们测量第七天所花的时间。 第七天是处理整个周的项目并更新关系图时处理时间最长的一天。 第八天的运行时间和磁盘使用率将与第一天类似。
分析处理对其运行所在的计算机并无太大影响，我们仍能继续成功地为查询服务并使搜索驱动的网站上的内容保持最新。
下表总结了结果：
| 测试计划 | 更新关系图 | 运行时间（小时） | 总磁盘使用峰值 | 使用率分析磁盘使用峰值 |
|---|---|---|---|---|
| 第 1 天 | 否 | 02:35 | 2.65 GB | |
| 第 2 天 | 否 | 02:43 | ||
| 第 3 天 | 否 | 03:23 | ||
| 第 4 天 | 否 | 04:39 | ||
| 第 5 天 | 否 | 06:08 | ||
| 第 6 天 | 否 | 07:35 | ||
| 第 7 天 | 是 | 08:29 | 82.4 GB | 4 GB |
下图显示了每天的运行时间：
图 7：每天的运行时间（小时）
针对经过身份验证的用户的跨网站发布
SharePoint 发布通常在 Intranet 网站上使用。 通过使用 SharePoint Server 2013，这些网站也可以由跨网站发布提供支持。 下列章节介绍了规划使用经过身份验证的用户的跨网站发布网站时需要考虑的重要区别。 除下列章节中介绍的预期外，适用于匿名访问的网站的规则仍适用于经过身份验证的用户访问的网站。
缺乏匿名搜索结果缓存
正如前面的匿名搜索结果缓存一节中所述，此缓存仅对匿名访问 SharePoint 网站的用户有效。 与使用匿名搜索结果缓存的匿名访问的网站相比，经过身份验证的用户访问的网站的吞吐量将大大降低。 Intranet 网站通常很少收到与前一节中所述的那么高的负载（每秒页面访问数达 100 次）。 但这是需要考虑的重要区别。
在这些情况下，使用输出缓存可以在一定程度上缓解匿名搜索结果缓存的缺乏。 预计每秒页面访问数更大的跨网站发布网站应考虑启用输出缓存。
重要
内容搜索 Web 部件具有一个设置，如果启用，将在异步模式下运行。 输出缓存不适用于来自异步内容搜索 Web 部件的负载。
更大的搜索索引
根据部署 SharePoint Server 2013 的企业规模，SharePoint Server 2013 的 Intranet 部署通常会为大量文档编制索引。 这意味着对这些文档编制索引所需的搜索拓扑与上一节中所述的拓扑将有所不同。 若要适当调整 SharePoint 部署大小，请参阅 在 SharePoint Server 中规划搜索 。
就地创作发布
本部分提供使用 SharePoint Server 2013 的指导和结果，但不详细说明影响容量规划的不同功能。 有关此区域的详细信息，请参阅 SharePoint Server 中的 Web 内容管理。
针对匿名用户的就地创作发布
在测试中，我们使用了具有以下特征的网站：
具有多达 20,000 个文章页的网站分为 20 个文件夹，每个文件夹包含单个网站集内 50 个网站的 1,000 个页面。
网站使用结构化导航。
网站通常每秒至少被访问 50 至 100 次。
通信模式涉及以下页面组合：
包含单个内容查询 Web 部件的 20 个页面，该 Web 部件发出不同范围的内容数据库查询（20% 的通信）
包含多个内容查询 Web 部件的 30 个页面，Web 部件发出不同范围的内容数据库查询（30% 的通信）
1600 篇文章，其中包含 40k 文本和两张图片（接收 50% 的通信）
建议的服务器拓扑如下图所示：
图 8：就地创作发布测试拓扑
1 台承载 SQL Server 的计算机
1 台作为前端 Web 服务器承载 SharePoint 服务应用程序的计算机
测试实验室结果
我们在测试实验室中使用了上图中所示的拓扑，其中使用物理计算机和 Visual Studio Team System 负载测试。
下表显示了我们在所测试的计算机中使用的技术规范：
| 服务器组件 | SharePoint Server |
|---|---|
| 处理器 | Intel Xeon CPU，2.33GHz（2 个处理器，共 8 个内核和 8 个线程） |
| RAM | 24 GB |
| 操作系统 | Windows Server 2008 R2 企业版，64 位 |
| 网络适配器数量 | 2 |
| 网络适配器速度 | 1 GB |
| 身份验证 | 无 - 匿名 |
| 负载平衡器类型 | Windows 软件负载平衡器 |
| 软件版本 | SharePoint Server 2013 |
| 服务器组件 | 数据库服务器 |
|---|---|
| 处理器 | Intel Xeon CPU MP7130M，2.79GHz（2 个处理器，共 8 个内核和 16 个线程） |
| RAM | 16 GB |
| 操作系统 | Windows Server 2008 R2 企业版，64 位 |
| 磁盘阵列 | 2 x Dell PERC 5/E |
| 网络适配器数量 | 1 |
| 网络适配器速度 | 1 GB |
| 身份验证 | NTLM |
| 软件版本 | Microsoft SQL Server 2008 R2 SP1 |
下表显示了运行 10 分钟后的结果：
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户数： | 5 | 15 |
| 50% 服务器响应时间： | 69 毫秒 | 112 毫秒 |
| 95% 服务器响应时间： | 92 毫秒 | 221 毫秒 |
| 每秒页面访问数： | 57 | 93 |
| 平均 CPU（应用程序服务器和前端 Web 服务器） | 55 | 97 |
| 平均 CPU (SQL Server) | 7 | 9 |
| 内存使用峰值（应用程序服务器和前端 Web 服务器） | 8.9 GB | 8.9 GB |
输出缓存的效果
输出缓存是在发布方案中减少 SharePoint Server 2013 上的负载的有效方法。 有关详细信息，请参阅在 SharePoint Server 中规划缓存和性能。
下表显示了在启用输出缓存的情况下，以 90% 命中率运行 10 分钟的结果：
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户数： | 5 | 15 |
| 50% 服务器响应时间： | 2 毫秒 | 2 毫秒 |
| 95% 服务器响应时间： | 74 毫秒 | 88 毫秒 |
| 每秒页面访问数： | 190 | 418 |
| 平均 CPU（应用程序服务器和前端 Web 服务器） | 58 | 85 |
| 平均 CPU (SQL Server) | 5 | 7 |
| 内存使用峰值（应用程序服务器和前端 Web 服务器） | 9.2 GB | 9.4 GB |
测试结果显示，使用输出缓存可以大大增加 SharePoint 发布网站的吞吐量，并缩短服务器响应时间。 对于从输出缓存提供服务的请求，响应时间接近即时。
下图显示了测试结果摘要：
图 9：90% 缓存命中率的输出缓存的效果
托管导航的效果
在 SharePoint Server 2013 中，发布网站也可以使用托管导航。 有关如何设置此功能的详细信息，请参阅 SharePoint Server 中的托管导航概述。
我们对使用托管导航的测试网站运行了与结构化导航测试相同的测试集。 我们的测试发现，使用托管导航或结构化导航时，网站的性能并无太大区别。
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户数： | 5 | 15 |
| 50% 服务器响应时间： | 70 毫秒 | 111 毫秒 |
| 95% 服务器响应时间： | 95 毫秒 | 215 毫秒 |
| 每秒页面访问数： | 56 | 94 |
| 平均 CPU（应用程序服务器和前端 Web 服务器） | 54 | 97 |
| 平均 CPU (SQL Server) | 7 | 9 |
| 内存使用峰值（应用程序服务器和前端 Web 服务器） | 8 GB | 8 GB |
下图显示了同一个网站不同类型的导航：
图 10：托管导航与结构化导航
添加计算机（向外扩展）的效果
如果发现需要 SharePoint 部署中的更多吞吐量，可以考虑横向扩展 (增加托管 SharePoint Server 2013) 的计算机数。 下图显示了我们在向服务器场添加更多计算机时吞吐量的增加情况：
图 11：增加前端 Web 服务器对吞吐量的影响
在我们的测试中，我们为添加的每台计算机增加了运行 SharePoint Server 2013 的服务器上的负载，使服务器响应时间大致相同， (绿色区域大约为 11 毫秒，红色区域) 大约为 250 毫秒。
针对经过身份验证的用户的就地创作发布网站
SharePoint 发布功能通常用于用户需经过身份验证才能访问网站的 Intranet。 本节介绍了使用经过身份验证的用户的测试及其效果。
下表显示了经过身份验证的用户通过 NTLM 基于声明的身份验证来访问的就地创作网站的测试结果。 请注意，这些测试使用与前一节中的测试相同的硬件。
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户数： | 5 | 15 |
| 50% 服务器响应时间： | 76 毫秒 | 107 毫秒 |
| 95% 服务器响应时间： | 103 毫秒 | 194 毫秒 |
| 每秒页面访问数： | 54 | 100 |
| 平均 CPU（应用程序服务器和前端 Web 服务器） | 50 | 97 |
| 平均 CPU (SQL Server) | 6 | 9 |
| 内存使用峰值（应用程序服务器和前端 Web 服务器） | 9.5 GB | 9.5 GB |
这些数字显示，匿名请求和经过身份验证的请求的服务器响应时间和吞吐量差别不大。
下图显示了同一个网站不同类型的请求：
图 12：匿名请求与经过身份验证的请求
输出缓存在经过身份验证的方案中的效果
对服务器的经过身份验证的请求需要往返到内容数据库，以确保访问内容的帐户具有查看内容的权限。 这意味着经过身份验证的网站的输出缓存性能特性与匿名网站有所不同。
下表显示了在启用输出缓存的情况下，以 90% 缓存命中率在 10 分钟内收到的结果：
| 测试功能 | 绿色区域 | 红色区域 |
|---|---|---|
| VSTS 用户数： | 6 | 18 |
| 50% 服务器响应时间： | 17 毫秒 | 29 毫秒 |
| 95% 服务器响应时间： | 87 毫秒 | 118 毫秒 |
| 每秒页面访问数： | 114 | 236 |
| 平均 CPU（应用程序服务器和前端 Web 服务器） | 50 | 97 |
| 平均 CPU (SQL Server) | 7 | 10 |
| 内存使用峰值（应用程序服务器和前端 Web 服务器） | 9.9 GB | 10 GB |
下图显示了这些结果的摘要：
图 13：经过身份验证的输出缓存的效果
另请参阅
概念
在 SharePoint Server 中规划 Web 内容管理
在 SharePoint Server 中配置 Web 内容管理解决方案