azure-cognitive-search - 如何消除 Azure 搜索服务 API 限制

Question

我们的目标是完全消除 Azure 搜索服务限制。最初，我们从 S1 层上的 3 个副本和 1 个分区开始。我们遇到了很多限制，有时甚至有多达 1.5% 的请求受到限制。我们采取了一些措施来缓解这个问题:

1) - 我们开始对服务进行负载测试，并提出了 3 个副本的基线请求/秒。每次我们达到约 37 个请求/秒时，我们的服务就会受到限制。

2) - 我们不希望用户看到错误，为了缓解问题，我们实现了指数退避 transient 故障策略，该策略会在 Azure 搜索 API 返回 5xx 或 408(请求超时)响应时重试调用。这对我们来说效果很好。

3)问题依然存在；我们仍然受到每秒 37 个请求的限制，这对我们来说似乎很低。这意味着我们大致获得每个副本的最大~12 req/sec。因此，我们对查询进行了性能调整(从索引中删除了方面、高基数字段，清理了字段属性并确保索引执行最低限度的操作)，我们的查询速度加快了一些，并且对限制前端没有太大影响。

4) 所以我们决定增加五个副本来摆脱限制。我们再次进行了负载测试，现在该服务可以处理约 59 个请求/秒的基线。这再次变为每个副本~12 个请求/秒

每个副本

~12 个请求/秒 对于标准层服务器来说容量似乎较低。这对我们来说是一个巨大的问题，因为我们的流量只会增加(更不用说处理讨厌的机器人流量)

这些基准数字对于 Azure 搜索团队来说是否正确？

或者我们做错了什么？如果需要，我可以提供搜索查询。

任何帮助将不胜感激!

谢谢!

Answer 1

Azure 搜索中的规模是一个复杂的主题。我推荐以下内容:

1. 评论 Deployment strategies and best practices for optimizing performance on Azure Search

2. 来自 Develop baseline numbers :

   Azure Search does not run indexing tasks in the background. If your service handles query and indexing workloads concurrently, take this into account by either introducing indexing jobs into your query tests, or by exploring options for running indexing jobs during off peak hours.

   如果您在查询时同时运行索引作业，请考虑在非高峰时段运行它们或进一步扩大规模

3. 您提到您觉得请求率太低，每秒 12 个请求。您似乎已经采取了性能优化页面上列出的一些步骤，包括从索引中删除高基数字段。我怀疑您的单个查询速度很慢，您会考虑增加分区数量吗？

来自Scaling for slow individual queries :

A partition is a mechanism for splitting your data across extra resources. Adding a second partition splits data into two, a third partition splits it into three, and so forth. One positive side-effect is that slower queries sometimes perform faster due to parallel computing. We have noted parallelization on low selectivity queries, such as queries that match many documents, or facets providing counts over a large number of documents. Since significant computation is required to score the relevancy of the documents, or to count the numbers of documents, adding extra partitions helps queries complete faster.

如果您分享您的查询、示例记录的外观以及您的索引中有多少条记录，我们可以提供更详细的建议。