为什么Azure搜索需要1400毫秒才能返回简单查询的查询结果 [英] Why is Azure Search taking 1400 miliiseconds to return query results for simple query
问题描述
我在azure搜索中有一个索引，其中包含以下json
I have an index in azure search which has the following json
"id": "1847234520751",
"orderNo": "1847234520751",
"orderType": "ONLINE",
"orderState": "OPROCESSING",
"orderDate": "2018-10-02T18:28:07Z",
"lastModified": "2018-11-01T19:13:46Z",
"docType": "SALES_ORDER",
"paymentType": "PREPAID",
"buyerInfo_primaryContact_name_firstName": "",
"buyerInfo_primaryContact_name_lastName": "",
"buyerInfo_primaryContact_email_emailAddress": "test@gmail.com"
我已经索引了将近80万个文档，并编写了以下JAVA代码来查询天蓝色搜索
I have indexed almost 0.8 million documents and have written the following JAVA code to query azure search
IndexSearchOptions options = new IndexSearchOptions();
options.setSearchFields("orderNo");
long startTime1 = System.currentTimeMillis();
IndexSearchResult result = indexClient.search(filter, options);
long stopTime1 = System.currentTimeMillis();
long elapsedTime1 = stopTime1 - startTime1;
System.out.println("elapsed time " + elapsedTime1);
此操作的时间为 1400毫秒.如果有人可以帮助我减少这段时间，那真的会很有帮助
The timings for this comes out to be 1400 miliseconds. If anyone can help me reduce this time, it would be really really helpful
推荐答案
如果您尝试仅基于orderNo返回文档，而不是进行全文搜索，则建议使用查找" API进行操作所以
If you are trying to simply return a document based on an orderNo, rather than doing a full text search, I would recommend using the "Lookup" API to do so
https://docs.microsoft.com/en -us/rest/api/searchservice/lookup-document
此外，使用客户端计时器来计算经过的时间不会给您准确的结果.经过的时间将受到许多因素的影响，包括您的客户端计算机配置和网络性能.如果您对服务器处理您的请求花了多少时间感兴趣，我建议尝试使用REST api，然后检查搜索查询的响应标头中的经过时间"值.这将节省您在网络上花费的所有时间，因此对于监视您的搜索效果将更为有用.如果这样做，我建议运行多个查询，然后将平均经过时间作为指标.
Also, using a client side timer to calculate elapsed time will not give you accurate results. The time elapsed will be affected by many factors, including your client machine configuration and your network performance. If you are interested in how much time it took the server to process your request, I would suggest experimenting with the REST api, and then inspect the "elapsed-time" value in the response header of your search query. This will be more useful for monitoring your search performance as it will omit any time spent on the network. If you do so, I would suggest running multiple queries and then take the average elapsed time as a metric.
如果您看到经过的时间很快，但是由于网络性能问题，搜索查询仍然相对较慢，那么请确保在两次调用之间重新使用Search Client对象，而不是为调用创建一个新的对象.每个呼叫，因为这是查询无法获得最佳延迟的常见原因.
If you see that te elapsed time is quick, but that the search query it still relatively slow due to network performance issues, then make sure to re-use the Search Client object in between calls, rather than creating a new one for each call, as this is a common reason queries do not get optimal latency.
最后，这是有关调整Azure搜索服务性能的完整文章.
Finally, here's a full article about tuning performance for your Azure Search service.
https://docs.microsoft.com/en -us/azure/search/search-performance-optimization
在您的情况下，您似乎正在尝试提高单个查询的性能，而不是尝试增加一次可以处理的查询数量.如果您的查询特别复杂(例如，尝试在使用排序和分面时返回大量文档)，则增加分区数可能会有所帮助，因为您的80万个文档将分布在多台计算机上，从而使每台计算机都可以执行搜索并行处理更少量的文档，而不是依靠一台计算机来处理全部负载.但是，在您的情况下，查询看起来相对简单，因此我的建议是如上所述，首先收集准确的指标，以了解瓶颈是在处理请求期间还是与网络相关.
In your case, it seems like you are trying to speed up single query performances, rather than trying to increase how many queries can be handled at once. If your query was particularly complex (e.g. trying to return a lot of documents while using sorting and faceting), increasing the number of partitions could help, as your 0.8 million document will be spread across multiple machines, allowing each of them to execute the search over a smaller amount of documents in parallel, rather than relying on a single machine to process the full load. However, in your case, the query look relatively simple, so my suggestion would be as I mentioned above and collect accurate metric first to understand if the bottleneck is during the processing of the request or if its network related.
希望这会有所帮助
这篇关于为什么Azure搜索需要1400毫秒才能返回简单查询的查询结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
