我看到Azure Search Basic实例的性能不稳定。我们的索引只有1,544个文档，大小为28MB，所以我希望搜索速度非常快。
Azure Application Insights在过去12小时内从我们的应用报告了对Azure搜索的4.7K调用，平均响应时间为2.1秒，标准差为35.8秒（！）。
我个人在手动测试期间看到不稳定的表现。一次查询可能需要20多秒，然后稍后相同的查询将花费不到100毫秒。
查询非常简单。这是一个示例查询字符串：
API-版本= 2015年2月28日＆安培; API-键=除去＆安培;搜索=安培;％24count =真安培;％24top = 10安培;％24skip = 0＆安培;搜索模式=所有＆安培; scoringProfile = FieldBoost＆安培;％24orderby = sortableTitle
如何进一步解决此问题？
答案 0 :(得分：2)
首先，我假设你有一个相当均匀的查询分布，这意味着根据你的数字，你每秒只有~1个查询。这听起来不对吗？如果没有，并且您看到大量查询，则很可能没有足够的副本（索引副本）来处理查询负载。请注意，单个副本基本服务的目标是处理低单位数QPS（尽管这可能因查询的复杂性或简单性而有很大差异）。如果超出服务范围，延迟肯定会成为一个问题。深入研究这一点的一个好方法是使用Azure Search Traffic Analytics，它可以公开包含数据的搜索指标，例如在不同时间范围内每秒查询的数量以及我们在内部看到的延迟指标。
此外，最重要的是，请尝试尽可能多地重用HTTP连接，并尽可能利用HTTP连接池。顺便说一句，在.NET中，如果使用我们的Azure搜索SDK，您应该重用单个HttpClient实例或SearchIndexClient实例。
答案 1 :(得分：0)
我在Azure搜索论坛收集了更多数据和posted my results。
减速是由于我们运行单个基本实例并且Azure搜索团队的代码部署导致服务中断/降级导致短暂（我的经验只有几分钟）。
我发现运行两个基本实例太贵了。除可用性外，我们的搜索流量不保证两个实例。
我从论坛中了解到，免费套餐的可用性通常高于单个基本实例。因此，我提交了一个feedback item建议付费共享层，它将提供比免费层更多的存储空间，同时保留比单个专用实例更高的可用性。