估计 Managed Metadata Service 的容量和性能 (SharePoint Server 2013)
适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
本文包含与 SharePoint Server 2013 中托管元数据服务的大小调整和性能优化相关的信息和建议。 我们还提供了有关如何配置服务和构建服务应用程序数据库以实现最大性能的最佳做法。 使用此信息确定您的规划部署是否符合我们的测试提供的容量和性能限制。
SharePoint Server 2013 中的以下新功能直接影响托管元数据服务，并且对于容量规划非常重要。 这些功能中的负载包含在我们的测试数据集和测试方案中。
“我的网站或工作组网站”) (源中的井号标签
使用托管导航的网站
客户端可以调用的新 CSOM 终结点
对于具有与测试数据集类似的特征的典型 SharePoint Server 2013 部署，我们建议托管元数据服务应用程序在承担前端 Web 服务器角色的计算机上运行。 托管元数据服务应用程序的数据库可以放在托管其他 SharePoint 服务应用程序数据库的 SQL Server 实例上。
对于所包含项目大大多于在测试中提供的数据集的部署，我们将尝试通过测试结果提供指导，我们可以在测试结果中更改一个变量，并将测试数据集的其他组件保持不变。 具有较大部署的用户应考虑这些结果，并相应地调整其 SharePoint Server 2013 场的大小。
有关容量管理和如何规划 SharePoint Server 2013 的常规信息，请参阅 SharePoint Server 2013 的容量管理和大小调整。
简介
建议在具有与测试数据集类似的特征的典型 SharePoint Server 2013 部署中，仅在作为前端 Web 服务器运行的计算机上启用托管元数据服务应用程序。 托管元数据服务应用程序的数据库可以放在托管其他 SharePoint 服务应用程序数据库的 SQL Server 实例上。
请注意，对于所包含项目大大多于我们在测试中提供的数据集的部署，我们提供了单独建议。 在测试中，我们尝试使用测试结果提供指导，我们会更改测试中的一个变量，并将其他组件保持不变。 使用更大部署的用户应考虑这些结果并相应地调整其 SharePoint 服务器场的大小。
测试数据集
为了提供容量规划指南，我们创建了一个测试数据集，其中包括 SharePoint Server 2010 中的功能和 SharePoint Server 2013 中的新功能，并在 SharePoint 部署上运行了测试。 下表显示了我们使用的测试数据集：
| "变量" | 项目数 |
|---|---|
|
术语集组 |
500 |
|
术语集 |
1,000（每个组 2 个） |
|
托管术语（不包括企业关键字） |
20,000（每个术语集 20 个） |
|
企业关键字 |
80,000 |
|
井号标签 |
200,000 |
|
总术语（包括托管术语、企业关键字和井号） |
300,000 |
|
标签 |
300,000（每个项目 1 个） |
|
术语标签长度 |
每个标签 30 个字符 |
测试方案
我们将下表中的测试用于此数据集：
| Test | 说明 | 测试百分比 |
|---|---|---|
|
GetSuggestions |
对 Web 服务的单个调用和单个字符前缀字符串。 将选择字符串以匹配术语存储中 20% 的术语，与元数据列建议在 SharePoint 用户界面中的工作方式类似。 |
10% |
|
GetMatches |
与术语存储中 1% 的术语匹配的字符串的 Web 服务。 |
5% |
|
ValidateTerms |
用于验证单个术语的 Web 服务调用。 |
5% |
|
CreateTaxonomyItem |
用于使用随机名称创建关键字的 Web 服务调用。 |
5% |
|
GetChildTermsInTermSetWithPaging |
对多个术语集的 Web 服务调用。 类似于 SharePoint Server 2013 调用来检索托管导航功能使用的术语集，其结果随后缓存在前端 Web 服务器中。 |
5% |
|
GetTermSets |
用于获取术语集的 Web 服务调用。 |
5% |
|
GetTermsByLabel |
使用术语 GUID 列表的 Web 服务调用。 类似于 SharePoint Server 2013 在加载“我的网站”主页时发出的调用。 |
10% |
|
HT GetSuggestions |
用于获取具有单个字符的井号建议的 Web 服务调用。 与您在源中使用井号时 SharePoint 发出的调用类似。 |
10% |
|
HT NewHashTag |
2 个 Web 服务调用。 一个用于获取术语，另一个用于创建术语。 |
5% |
|
HT GetTermsByLabel |
用于获取现有术语的 Web 服务调用。 当在源文章中使用井号时使用。 |
15% |
|
HT AddAssociation |
用于添加与现有井号术语的关联的 Web 服务调用。 |
5% |
|
CSOM GetTerms |
测试 GetTerms 以获取术语 GUID 列表。 具有两个单独的 CSOM 调用。 |
10% |
|
CSOM SetProperty |
对单个术语的 SetProperty 的测试。 具有四个单独的 CSOM 调用。 |
5% |
|
CSOM CreateTerm |
测试以向术语存储添加术语。 具有四个单独的 CSOM 调用。 |
5% |
在我们的测试中，我们更加侧重于预期使用更频繁的操作。
测试拓扑
我们在拓扑如下图所示的实验室环境中运行测试：
图 1：测试实验室服务器拓扑
我们使用一台运行 Managed Metadata Service 应用程序并充当前端 Web 服务器的计算机上启动测试。 稍后，我们添加了另一台具有相同配置的计算机。
测试结果
我们使用前面章节中所述的数据集和方案，来测试对指定配置执行的 Managed Metadata Service 应用程序操作总数。
我们使用以下列表中的不同负载配置文件运行我们的测试：
绿色区域
服务器的利用率低于 60%。 这应该是大部分时间下服务器运行的目标。
红色区域
服务器接近完全利用。 这可以视为 SharePoint 网站所承受的负载比平常多的一种状态。 在红色区域中，服务器响应时间开始增加，因为服务器需尽力满足传入请求的需求。
下表显示了我们在一台计算机中的测量结果：
| 绿色区域 | 红色区域 | |
|---|---|---|
|
读取操作为 50% 服务器响应时间： |
32 毫秒 |
44 毫秒 |
|
读取操作为 95% 服务器响应时间： |
1090 毫秒 |
1335 毫秒 |
|
写入操作为 50% 服务器响应时间： |
1837 毫秒 |
2038 毫秒 |
|
写入操作为 95% 服务器响应时间： |
2283 毫秒 |
3515 毫秒 |
|
每秒钟完成的测试数： |
9 |
15 |
|
平均 CPU（应用程序服务器或前端 Web 服务器） |
56% |
92% |
|
平均 CPU (SQL Server) |
7% |
12% |
|
内存使用峰值（应用程序服务器或前端 Web 服务器） |
6 GB |
6.2 GB |
然后我们向使用相同配置的部署中添加了第二台应用程序服务器或前端 Web 服务器虚拟机 (VM)。 下表显示了负载大约为之前测试中的两倍 (2x) 负载、包含两个 VM 的服务器场的结果。
| 绿色区域 | 红色区域 | |
|---|---|---|
|
读取操作为 50% 服务器响应时间： |
44 毫秒 |
110 毫秒 |
|
读取操作为 95% 服务器响应时间： |
1161 毫秒 |
1679 毫秒 |
|
写入操作为 50% 服务器响应时间： |
1828 毫秒 |
2253 毫秒 |
|
写入操作为 95% 服务器响应时间： |
3321 毫秒 |
4648 毫秒 |
|
每秒钟完成的测试数： |
15 |
28 |
|
平均 CPU（应用程序服务器或前端 Web 服务器） |
49% |
88% |
|
平均 CPU (SQL Server) |
14% |
28% |
|
内存使用峰值（应用程序服务器和前端 Web 服务器） |
6.1 GB |
6.3 GB |
下图显示了前两个表中的数据：
图 2：Managed Metadata Service 应用程序性能
友好 URL 对友好 URL 搜索爬网的影响
SharePoint Server 2013 包括托管导航功能和两个计时器作业，它们被触发以确保搜索爬网接收使用友好 URL 的最新版本页面。 我们在测试中发现，运行这些与 Managed Metadata Service 应用程序通信的计时器作业对以相同应用程序为目标的读写操作没有重大影响。
CSOM 调用的影响
与基准案例相比，有些测试会增加在测试过程中发出的 CSOM 调用。 我们将其从测试的 20% 增加到了 66%。 测试结果显示，执行的测试数量从每秒 28 个下降到 22 个。 服务器响应时间与基线相差无几。 执行的测试数量下降的原因在于，与 Web 服务调用中涉及的较少调用相比，对于 CSOM 调用的每个操作，对前端 Web 服务器的多个调用的成本增加了。
具有更多井号运算的影响
在另一个测试案例中，我们将井号运算的百分比从基线中的 35% 提高到了测试中的 71%。 结果显示，执行的测试数量从 28 个下降到 19 个。 服务器响应时间大约比基线增加了 30%。 执行测试的数量下降的原因在于，井号术语集中的术语数量相当高，且更改过程中的写入操作百分比大大增加。