估计 Web 内容管理的容量和性能 (SharePoint Server 2013)

 

**上一次修改主题：**2017-08-25

**摘要：**了解如何确定在 SharePoint Server 2013 中发布内容和管理 Web 内容时所需的计算机数量和类型。

企业通常使用SharePoint Server 2013来发布互联网网站或程序上的匿名用户访问身份验证用户访问 intranet 站点上的内容。本文以帮助计划要使用的计算机的数量和类型需要发布内容并管理中SharePoint Server 2013的 web 内容的计算机的容量和性能数据。

本文内容：

• 简介

• 先决条件信息

• 使用托管导航进行跨网站发布

• 就地创作发布

SharePoint 发布包含不同类型的发布网站和每个站点有关联的方法。SharePoint Server 2013的发布功能旨在帮助创建带有商标信息的互联网、 企业网和 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 使用率数据库中针对特定请求记录的"持续时间"来测量这两个值。

• 内容新鲜度

  更新项反映在搜索结果中所需的时间是使用跨网站发布方案时需考虑的指标。

本文中的方案使用以下两种状态：

• 绿色区域

  服务器的利用率低于 60%。这应该是大部分时间下服务器运行的目标。

• 红色区域

  服务器接近完全利用。这可以视为 SharePoint 网站所承受的负载比平常多的一种状态。在红色区域中，服务器响应时间开始增加，因为服务器需尽力满足传入请求的需求。

先决条件信息

在阅读本文之前，请确保您了解SharePoint Server 2013容量管理的重要概念。下面的文章将帮助您了解有关容量管理建议的方法和来龙去脉，可以帮助您了解如何在这篇文章中进行信息的有效使用。

请注意，本文中不涉及影响发布方案功能的其他新功能。这些方案包括设备渠道、SEO 优化、显示模板和查询规则。此外，本文未详细介绍跨网站发布网站的功能和配置。有关详细信息，请参阅在 SharePoint Server 中规划跨网站发布和在 SharePoint 服务器上配置 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：测试实验室服务器拓扑

• 一台在 SharePoint 使用的所有数据库中承载 SQL Server 的计算机

• 一台承载 SharePoint 服务应用程序、分布式缓存服务、搜索分析处理和搜索管理角色的计算机

• 一台承载搜索爬网程序和内容处理 (CPC) 角色的计算机

• 三台承载查询处理的搜索索引节点并充当前端 Web 服务器的计算机

备注

此测试中的计算机是运行 Windows Server 2008 R2 的物理计算机。请参阅搜索容量规划和 SharePoint Server 2013 的容量规划了解有关如何使用虚拟机和 Windows Server 2012 的建议。

重要

我们的测试实验室拓扑配置针对搜索驱动的发布方案进行了优化。此配置不同于 SharePoint 部署的协作类型。例如，我们的配置使用前端 Web 服务器作为搜索索引服务器来实现最佳性能。
在我们的测试实验室拓扑中，我们了解到承载应用程序服务器的计算机未充分利用。因此，我们将分布式缓存服务放在此应用程序服务器，而不是专用服务器上。您可能决定在环境中的专用服务器上承载分布式缓存服务。为实现最佳性能，我们建议您不要在具有搜索索引服务器角色的前端 Web 服务器上承载分布式缓存服务。

测试实验室报告

我们为我们与物理计算机和 Visual Studio 团队系统 (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 Enterprise 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 Enterprise 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以并行方式执行多达五个查询并返回结果。如果超过 5 个查询页上， SharePoint Server 2013之前它开始执行下一组五个查询执行的前五个查询。如果页面需要五个以上内容搜索 Web 部件或目录项重复使用的 Web 部件，可能在异步模式下运行其他内容的搜索 Web 部件，或使用查询规则和结果块。

• 内容搜索 Web 部件和目录项重用 Web 部件具有异步模式。与 Web 部件相关的查询将在浏览器加载页面后执行。对于缓慢查询，使用此模式，以便页面的其余部分更快地向用户显示。否则，我们建议您使用同步查询，以获得最佳页面加载时间。

• 具有多个精简条件的精简面板 Web 部件会增加查询处理时间。您可以更改为托管属性显示的精简条件数。有关详细信息，请参阅在 SharePoint 服务器上配置精简将和多面导航。

• 如果您在具有导航节点深层次结构时使用分类精简面板 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 利用率下运行。

我们建议您对网站上的热门页面使用输出缓存，例如网站的主页或首要类别页以及接收大量通信的特定项目页。

重要

已启用了输出缓存的页还包含内容搜索 Web 部件时有中SharePoint Server 2013是一个已知的问题。若要避免此问题，您的部署中，安装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：每天的运行时间（小时）

针对经过身份验证的用户的跨网站发布

在 intranet 站点上通常使用 SharePoint 发布。通过使用SharePoint Server 2013，这些网站也可以通过跨站点发布供电。以下部分显示了一些重要的差别，要考虑跨站点发布站点使用身份验证的用户的计划时。除以下各节中提到的例外，适用于匿名访问站点的规则仍适用于经过身份验证的用户访问的站点。

缺乏匿名搜索结果缓存

正如前面的匿名搜索结果缓存一节中所述，此缓存仅对匿名访问 SharePoint 网站的用户有效。与使用匿名搜索结果缓存的匿名访问的网站相比，经过身份验证的用户访问的网站的吞吐量将大大降低。Intranet 网站通常很少收到与前一节中所述的那么高的负载（每秒页面访问数达 100 次）。但这是需要考虑的重要区别。

在这些情况下，使用输出缓存可以在一定程度上缓解匿名搜索结果缓存的缺乏。预计每秒页面访问数更大的跨网站发布网站应考虑启用输出缓存。

重要

内容搜索 Web 部件具有一个设置，如果启用，将在异步模式下运行。输出缓存不适用于来自异步内容搜索 Web 部件的负载。

更大的搜索索引

企业部署SharePoint Server 2013的大小，根据SharePoint Server 2013的 intranet 部署通常索引数量更大的文档。这意味着将不同相较于上一节中介绍的拓扑所需的搜索拓扑，以便文档编入索引。请参阅在 SharePoint Server 中规划搜索以 SharePoint 部署正确的尺寸。

就地创作发布

本部分提供了指导和结果，使用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 Enterprise，64 位
网络适配器数量	2
网络适配器速度	1 GB
身份验证	无 ─ 匿名
负载平衡器类型	Windows 软件负载平衡器
软件版本	SharePoint Server 2013

服务器组件	数据库服务器
处理器	Intel Xeon CPU MP7130M，2.79GHz（2 个处理器，共 8 个内核和 16 个线程）
RAM	16 GB
操作系统	Windows Server 2008 R2 Enterprise，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：经过身份验证的输出缓存的效果

See also

在 SharePoint Server 中规划 Web 内容管理
在 SharePoint 服务器上配置 web 内容管理解决方案
管理 SharePoint 服务器中的 web 内容管理
Configure cache settings for a web application in SharePoint Server
在 SharePoint Server 中规划缓存和性能