如何消除 Azure 搜索服务 API 限制

Question

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

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

2)- 我们不希望我们的用户看到错误并缓解问题，我们实施了指数退避瞬态故障策略，当 Azure 搜索 API 返回 5xx 或 408（请求超时）响应时重试调用。这对我们很有效。

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

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

~12 requests/sec 每个副本似乎对于标准层服务器来说容量很低。这对我们来说是一个大问题，因为我们的流量只会增加（更不用说处理讨厌的机器人流量了）

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

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

任何帮助将不胜感激！

谢谢！

Answer 1

Azure 搜索中的缩放是一个复杂的主题。我推荐以下：

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

2. 来自Develop baseline numbers：

   Azure 搜索不会在后台运行索引任务。如果您的服务同时处理查询和索引工作负载，请通过在查询测试中引入索引作业或探索在非高峰时段运行索引作业的选项来考虑这一点。

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

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

来自Scaling for slow individual queries：

分区是一种将数据拆分到额外资源中的机制。添加第二个分区将数据拆分为两个，第三个分区将其拆分为三个，依此类推。一个积极的副作用是，由于并行计算，较慢的查询有时会执行得更快。我们注意到低选择性查询的并行化，例如匹配许多文档的查询，或提供大量文档计数的方面。由于需要大量计算来对文档的相关性进行评分或计算文档的数量，因此添加额外的分区有助于更快地完成查询。

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

Answer 2

感谢马修的详细回复！

1) 我们遵循了这里提到的策略：Deployment strategies and best practices for optimizing performance on Azure Search

2) 我们曾考虑在非高峰时段运行索引器，但我们的用例需要我们更频繁地运行索引（设置为每 15 分钟运行一次）

3) 是的，我们的查询可能有点复杂。

索引大小：160K 行； 字段数：108

这是来自我们的登录页面的示例查询：

    "$count=false&facet=IsUsed,count:500&facet=Year,count:500&facet=ChassisMake,count:500&facet=ChassisModel,count:500&facet=NormalTrim,count:500&facet=CabType,count:500&facet=RoofHeight,count:500&facet=ChassisType,count:500&facet=DriveTrain,count:500&facet=RearWheels,count:500&facet=FuelType,count:500&facet=NormalEngine,count:500&facet=NormalTransmission,count:500&facet=NormalColor,count:500&facet=GVWR,count:500&facet=Wheelbase,count:500&facet=CA,count:500&facet=BodyType,count:500&facet=BodyMake,count:500&facet=HasSnowPlow,count:500&facet=HasCrane,count:500&facet=HasVanPartition,count:500&facet=BodyLength,count:500&facet=DealerNumericID,count:2000&$filter=((search.in(CMID, '5e3c3789-bb0f-4e6a-8c8b-a0fc31568d85') ) and ( HasLiftKit eq null )) and (IsDealerLive eq true) and  IsDemoDealer eq false  and  DepartureDate eq null and  IsUsed eq false  and geo.distance(GeoPoint, geography'POINT(-121.141636 38.666597)') le 80&queryType=simple&scoringParameter=IsUpfit-'true'&scoringParameter=GeoPoint-'-121.141636','38.666597'&scoringProfile=locator-distance&searchMode=any&$select=ID,DealerID,IsUsed,Featured,CustomTitle,StockNumber,CleanStockNumber,Vin,ChassisImagePathTemplate,ChassisBlobLastUpdated,BodyImagePathTemplate,BodyBlobLastUpdated,ChassisModelVINDecodingID,ChassisManufacturerID,BodyManufacturerID,BodyType_Code,ChassisMake,ChassisModel,DealerNumericID,Year,BodyTypeID,BodyType,EnabledAttributes,Mileage,CabType,DriveTrain,RearAxle,FuelType,Transmission,Color,RoofHeight,SalePrice,OnSale,SaleStartDate,SaleEndDate,SaleShowSaleBanner&$skip=0&$top=10
SearchString:*"

该查询在索引预热时会在 75 毫秒内运行，而在索引未预热时会在大约 300 毫秒内运行。

请告诉我们你的想法。

非常感谢！