分析 Azure AI 搜尋中的效能

發行項
11/15/2023

本文說明在 Azure AI 搜尋服務中分析查詢和編製索引效能的工具、行為和方法。

開發基準編號

在任何大型實作中，請務必先對 Azure AI 搜尋服務執行效能效能評定測試，再將其導入生產環境。您應該同時測試您預期的搜尋查詢負載，但也測試預期的數據擷取工作負載（可能的話，請同時執行這兩個工作負載）。具有基準檢驗號碼有助於驗證適當的搜尋層、服務設定，以及預期的查詢延遲。

若要開發基準檢驗，我們建議使用 azure-search-performance-testing （GitHub）工具。

若要隔離分散式服務架構的影響，請嘗試測試一個複本和一個分割區的服務組態。

注意

針對儲存體優化層（L1 和 L2），您應該預期查詢輸送量較低，延遲比標準層高。

使用資源記錄

系統管理員處置最重要的診斷工具是資源記錄。資源記錄是有關搜尋服務的作業數據和計量的集合。資源記錄是透過 Azure 監視器啟用。使用 Azure 監視器和儲存數據時會有相關成本，但如果您為服務啟用它，則有助於調查效能問題。

下圖顯示查詢要求和回應中的事件鏈結。不論是在網路傳輸期間、在應用程式服務層中處理內容，還是搜尋服務，都可能發生延遲。資源記錄的主要優點是從搜尋服務觀點記錄活動，這表示記錄檔可協助您判斷效能問題是否因查詢或編製索引問題，或其他一些失敗點所造成。

資源記錄可讓您選擇儲存記錄的資訊。建議您使用 Log Analytics ，以便對數據執行進階 Kusto 查詢，以回答許多有關使用量和效能的問題。

在搜尋服務入口網站頁面上，您可以透過診斷設定啟用記錄，然後選擇 [記錄]，對Log Analytics發出 Kusto 查詢。如需設定的詳細資訊，請參閱收集和分析記錄數據。

節流行為

當搜尋服務處於容量時，就會發生節流。在查詢或編製索引期間可能會發生節流。從用戶端，API 呼叫會在節流時產生 503 HTTP 回應。在編製索引期間，也有可能接收 207 HTTP 回應，這表示一或多個專案無法編製索引。此錯誤是搜尋服務接近容量的指標。

根據經驗法則，請嘗試量化節流的數量和任何模式。例如，如果一個超過 500,000 個搜尋查詢已節流，則可能不值得調查。不過，如果在一段時間內節流了大量查詢，這會是比較關心的問題。藉由查看一段時間的節流，它也有助於識別節流可能更可能發生的時間範圍，並協助您決定如何最好地容納這一點。

對大部分節流問題的簡單修正，是在搜尋服務中擲回更多資源（通常是查詢型節流的複本，或索引編製型節流的數據分割）。不過，增加複本或分割區會增加成本，這就是為什麼必須知道節流發生的原因。接下來的幾個小節將說明調查造成節流的情況。

以下是 Kusto 查詢的範例，可識別已載入之搜尋服務的 HTTP 回應明細。在 7 天的期間內，轉譯的條形圖顯示，相較於成功（200）回應的數目，搜尋查詢的節流比例相對較大。

AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize count() by resultSignature_d 
| render barchart

檢查特定時段的節流，可協助您識別節流可能更頻繁發生的時間。在下列範例中，會使用時間序列圖表來顯示在指定時間範圍內發生的節流查詢數目。在此情況下，節流查詢會與執行效能效能評定的時間相互關聯。

let ['_startTime']=datetime('2021-02-25T20:45:07Z');
let ['_endTime']=datetime('2021-03-03T20:45:07Z');
let intervalsize = 1m; 
AzureDiagnostics 
| where TimeGenerated > ago(7d)
| where resultSignature_d != 403 and resultSignature_d != 404 and OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete")
| summarize 
  ThrottledQueriesPerMinute=bin(countif(OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete") and resultSignature_d == 503)/(intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart

測量個別查詢

在某些情況下，測試個別查詢以查看其執行方式很有用。若要這樣做，請務必瞭解搜尋服務完成工作所需的時間，以及從用戶端到客戶端進行來回要求所需的時間。診斷記錄可用來查閱個別作業，但從 REST 用戶端執行這項作業可能比較容易。

在下列範例中，會執行以 REST 為基礎的搜尋查詢。 Azure AI 搜尋會在每個回應中包含完成查詢所花費的毫秒數，其會顯示在 [標頭] 索引卷標的 [經過時間] 中。在回應頂端的 [狀態] 旁邊，您會看到往返持續時間，在此案例中為 418 毫秒（毫秒）。在結果區段中，已選擇 [標頭] 索引標籤。使用下圖中以紅色方塊反白顯示的這兩個值，我們看到搜尋服務花費 21 毫秒來完成搜尋查詢，而整個用戶端來回要求花費 125 毫秒。藉由減去這兩個數位，我們可以判斷將搜尋查詢傳送至搜尋服務，並將搜尋結果傳送回用戶端需要 104 毫秒的時間。

這項技術可協助您將網路等待時間與影響查詢效能的其他因素隔離。

查詢速率

搜尋服務節流要求的其中一個可能原因是執行大量查詢，其中磁碟區會擷取為每秒查詢（QPS）或每分鐘查詢（QPM）。當您的搜尋服務收到更多 QPS 時，回應這些查詢通常需要更長的時間和更長的時間，直到無法再跟上，因為它會傳回節流 503 HTTP 回應。

下列 Kusto 查詢會顯示以 QPM 測量的查詢量，以及以毫秒為單位的平均查詢持續時間，以及每個查詢中傳回的平均文件數（AvgDocCountReturned）。

AzureDiagnostics
| where OperationName == "Query.Search" and TimeGenerated > ago(1d)
| extend MinuteOfDay = substring(TimeGenerated, 0, 16) 
| project MinuteOfDay, DurationMs, Documents_d, IndexName_s
| summarize QPM=count(), AvgDuractionMs=avg(DurationMs), AvgDocCountReturned=avg(Documents_d)  by MinuteOfDay
| order by MinuteOfDay desc 
| render timechart

提示

若要顯示此圖表背後的數據，請移除線條 | render timechart ，然後重新執行查詢。

索引編製對查詢的影響

查看效能時要考慮的一個重要因素，是索引編製會使用與搜尋查詢相同的資源。如果您要編製大量內容的索引，當服務嘗試容納這兩個工作負載時，可能會看到延遲成長。

如果查詢速度變慢，請查看索引活動的時間，以查看其是否與查詢降低一致。例如，索引器可能正在執行與搜尋查詢效能降低相互關聯的每日或每小時作業。

本節提供一組查詢，可協助您將搜尋和編製索引速率可視化。針對這些範例，時間範圍是在查詢中設定。請務必指出在 Azure 入口網站中執行查詢時，在查詢中設定。

平均查詢延遲

在下列查詢中，間隔大小為1分鐘，用來顯示搜尋查詢的平均延遲。從圖表中，我們可以看到平均延遲很低，直到下午 5：45，持續到下午 5：53。

let intervalsize = 1m; 
let _startTime = datetime('2021-02-23 17:40');
let _endTime = datetime('2021-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime']..['_endTime']) // Time range filtering
| summarize AverageQueryLatency = avgif(DurationMs, OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete"))
    by bin(TimeGenerated, intervalsize)
| render timechart

每分鐘平均查詢 (QPM)

下列查詢會查看每分鐘的平均查詢數目，以確保搜尋要求中沒有可能影響延遲的尖峰。從圖表中，我們可以看到有一些差異，但沒有什麼可指出要求計數的尖峰。

let intervalsize = 1m; 
let _startTime = datetime('2021-02-23 17:40');
let _endTime = datetime('2021-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime'] .. ['_endTime']) // Time range filtering
| summarize QueriesPerMinute=bin(countif(OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete"))/(intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart

每分鐘編制索引作業 (OPM)

我們將在這裡查看每分鐘編製索引作業的數目。從圖表中，我們可以看到大量數據已從下午 5：42 開始編製索引，並在下午 5：50 結束。此索引編製開始於 3 分鐘之前，搜尋查詢開始成為潛伏，並在搜尋查詢不再延遲前 3 分鐘結束。

在此深入解析中，我們可以看到搜尋服務大約需要 3 分鐘的時間，才能開始忙碌，以便編製索引，以影響查詢延遲。我們也可以看到，在編製索引完成之後，搜尋服務需要 3 分鐘的時間才能從新編製索引的內容完成所有工作，以及查詢延遲才能解析。

let intervalsize = 1m; 
let _startTime = datetime('2021-02-23 17:40');
let _endTime = datetime('2021-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime'] .. ['_endTime']) // Time range filtering
| summarize IndexingOperationsPerSecond=bin(countif(OperationName == "Indexing.Index")/ (intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart

背景服務處理

查看查詢或編製索引延遲的定期尖峰並不罕見。針對索引編製或高查詢速率，可能會發生尖峰，但也可能在合併作業期間發生。搜尋索引會儲存在區塊或分區中。系統會定期將較小的分區合併成大型分區，這有助於將服務效能優化。此合併程式也會清除先前標示要從索引刪除的檔，進而復原儲存空間。

合併分區的速度很快，但也需要大量資源，因此可能會降低服務效能。如果您注意到查詢延遲的短暫高載，且這些高載與索引內容最近的變更一致，您可以假設延遲是因為分區合併作業所造成。

下一步

檢閱這些與分析服務效能相關的文章。