Azure AI 搜索性能基准

性能基准对于评估类似配置下的潜在性能非常有用。 实际性能取决于多种因素，包括搜索服务的大小以及要发送的查询的类型。

为帮助估计工作负载所需的搜索服务大小，我们运行了多种基准来记录不同搜索服务和配置的性能。

为涵盖一系列不同用例，我们针对两种主要场景运行了基准：

• 电子商务搜索 - 此基准模拟真实的电子商务场景，并基于北欧电子商务公司 CDON。
• 文档搜索 - 此场景由对 Semantic Scholar 中的全文文档的关键字搜索组成。 这模拟的是常见文档搜索解决方案。

尽管这些场景反映了不同的用例，但每种场景都不同，因此我们始终建议对单个工作负载进行性能测试。 我们使用 JMeter 发布了性能测试解决方案，因此你可以针对自己的服务运行类似测试。

测试方法

为了对 Azure AI 搜索的性能进行基准测试，我们在不同层和副本/分区组合针对两种不同场景运行了测试。

创建这些基准时，使用了以下方法：

1. 测试以每秒 X 个查询 (QPS) 的速度开始，持续 180 秒。 这通常为 5 或 10 QPS。
2. 然后，QPS 增加 X 并再次运行 180 秒
3. 每 180 秒，测试就会增加 X QPS，直到平均延迟增加到 1000 毫秒以上或查询成功率小于 99% 为止。

下图提供了测试查询负载情况的直观示例：

每种场景均使用了至少 10,000 个唯一的查询，以免测试因缓存而过度扭曲。

定义

• 最大 QPS - 最大 QPS 数基于测试中实现的最高 QPS，而该测试中 99% 的查询成功完成且未达到限制，平均延迟低于 1000 毫秒。

• 最大 QPS 的百分比 - 针对特定测试实现的最大 QPS 的百分比。 例如，如果在特定测试中达到了最大值 100 QPS，则最大 QPS 的 20% 为 20 QPS。

• 延迟 - 查询的服务器延迟；这些数字不包括往返延迟 (RTT)

。 值以毫秒 (ms) 为单位。

测试免责声明

azure-search-performance-testing 存储库中提供了我们用于运行这些基准测试的代码。 值得注意的是，与基准相比，JMeter 性能测试解决方案的 QPS 水平略低一些。 差异可能是由于测试样式不同。 这说明了尽量让性能测试与生产工作负载保持相似的重要性。

如果有任何疑问或疑虑，请通过 azuresearch_contact@microsoft.com 与我们联系。

基准 1：电子商务搜索

此基准与电子商务公司 CDON 合作创建，该公司是北欧地区最大的在线市场，在瑞典、芬兰、挪威和丹麦均开展业务。 CDON 通过其 1,500 位商家提供各式各样的产品类别，包含的产品超过 8 百万种。 2020 年，CDON 拥有的访客超过 1.2 亿，活跃客户达 200 万。 请参阅本文，了解有关 CDON 的 Azure AI 搜索使用情况的详细信息。

为了运行这些测试，我们使用了 CDON 的生产搜索索引的快照以及对其网站的数千次唯一查询。

场景详细信息

• 文档计数：6,000,000
• 索引大小：20 GB
• 索引架构：一种宽索引，其中共包含 250 个字段、25 个可搜索字段以及 200 个可查找/可筛选字段
• 查询类型：全文搜索查询，包括 facet、筛选器、排序和计分概要文件

S1 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	104 毫秒	35 毫秒	115 毫秒	177 毫秒	257 毫秒	738 毫秒
50%	140 毫秒	47 毫秒	144 毫秒	241 毫秒	400 毫秒	1175 毫秒
80%	239 毫秒	77 毫秒	248 毫秒	466 毫秒	763 毫秒	1752 毫秒

S2 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	56 ms	21 ms	68 毫秒	106 ms	132 毫秒	210 毫秒
50%	71 毫秒	26 毫秒	83 毫秒	132 毫秒	177 毫秒	329 毫秒
80%	140 毫秒	47 毫秒	153 ms	293 毫秒	452 毫秒	924 毫秒

S3 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

在本例中，我们看到，添加第二个分区会大幅增加最大 QPS，但添加第三个分区会导致边际收益递减。 收益减少可能是因为所有数据都已提取到仅包含两个分区的 S3 的有效内存。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	50 毫秒	20 ms	64 毫秒	83 毫秒	98 毫秒	160 ms
50%	62 毫秒	24 毫秒	80 ms	107 毫秒	130 毫秒	253 毫秒
80%	115 毫秒	38 毫秒	121 毫秒	218 毫秒	352 毫秒	828 毫秒

基准 2：文档搜索

场景详细信息

• 文档计数：750 万
• 索引大小：22 GB
• 索引架构：23 个字段；8 个可搜索，10 个可筛选/可查找
• 查询类型：关键字搜索，facet 和命中词突出显示

S1 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	67 毫秒	44 毫秒	77 毫秒	103 毫秒	126 毫秒	216 毫秒
50%	93 毫秒	59 毫秒	110 毫秒	150 毫秒	184 毫秒	304 毫秒
80%	150 毫秒	96 毫秒	184 毫秒	248 毫秒	297 毫秒	424 毫秒

S2 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	45 毫秒	31 毫秒	55 ms	73 ms	84 毫秒	109 毫秒
50%	63 毫秒	39 毫秒	81 毫秒	106 ms	123 毫秒	163 毫秒
80%	115 毫秒	73 ms	145 毫秒	191 毫秒	224 毫秒	291 毫秒

S3 性能

每秒查询次数

下图显示了较长时间内服务可以处理的最高查询负载，单位为每秒查询次数 (QPS)。

查询延迟

查询延迟因服务负载而异，压力越大的服务平均查询延迟越高。 下表显示了三种不同利用率级别在查询延迟时间占比为 25%、50%、75%、90%、95% 和 99% 时的情况。

最大 QPS 的百分比	平均延迟	25%	75%	90%	95%	99%
20%	43 毫秒	29 毫秒	53 毫秒	74 ms	86 毫秒	111 毫秒
50%	65 毫秒	37 毫秒	85 毫秒	111 毫秒	128 毫秒	164 毫秒
80%	126 毫秒	83 毫秒	162 毫秒	205 毫秒	233 毫秒	281 毫秒

要点

通过这些基准，你可以大致了解 Azure AI 搜索提供的性能。 还可以了解不同层上的服务之间的差异。

以下是这些基准的关键要点：

• 通常，S2 可处理的查询量至少是 S1 的四倍
• 在可比较的查询量下，S2 的延迟通常比 S1 更低
• 添加副本时，服务可处理的 QPS 通常呈线性缩放（例如，如果一个副本可处理 10 QPS，则 5 个副本通常可处理 50 QPS）
• 服务负载越高，平均延迟越高

你还了解到，不同场景之间的性能可能存在很大差异。 如果没有获得预期的性能，请查看提高性能的提示。

后续步骤

现在，你已了解性能基准，接下来可进一步了解如何分析 Azure AI 搜索的性能和影响性能的关键因素。

• 分析性能
• 提升性能的技巧