Azure AI 搜尋服務效能基準測試
重要
這些基準適用於 2024 年 4 月 3 日之前在舊基礎結構上執行之部署中建立的搜尋服務。 基準也僅適用於非向量的工作負載。 新限制上的服務和工作負載更新為擱置中。
效能基準對於估計類似設定下的潛在效能很有用。 實際效能取決於多種因素,包括搜尋服務的大小和您要傳送的查詢類型。
為了協助估計工作負載所需的搜尋服務大小,我們執行了數個基準來記錄不同搜尋服務和設定的效能。
為了涵蓋各種不同的使用案例,我們對兩個主要案例執行了基準測試:
- 電子商務搜尋 - 此基準測試會模擬實際的電子商務案例,其基礎為北歐的電子商務公司 CDON。
- 文件搜尋 - 此案例由對 Semantic Scholar 中的全文檢索文件的關鍵字搜尋所組成。 其模擬的是常見的文件搜尋解決方案。
雖然這些案例反映不同的使用案例,但每個案例都不同,因此我們始終建議對個別工作負載進行效能測試。 我們發佈了使用 JMeter 的效能測試解決方案,讓您能夠對自己的服務執行類似的測試。
測試方法
為了對 Azure AI 搜尋服務的效能進行基準測試,我們在不同層級和複本/分割區組合上對兩個不同的案例執行了測試。
為了建立這些基準測試,我們使用了下列方法:
- 測試從每秒
X
個查詢 (QPS) 開始,執行 180 秒。 此值通常是 5 或 10 QPS。 - 接著會將 QPS 增加
X
,並且再執行 180 秒 - 每隔 180 秒,測試就會增加
X
QPS,直到平均延遲提高到 1000 毫秒以上,或查詢成功率低於 99% 為止。
下圖顯示測試查詢負載的範例:
每個案例均至少使用 10,000 個獨特的查詢,以避免測試因快取而過度扭曲。
重要
這些測試僅包含查詢工作負載。 如果您預期會有大量的索引編製作業,在您進行估計和效能測試時請務必將這一點納入考量。 您可以在此教學課程中找到模擬索引編製的範例程式碼。
定義
最大 QPS - 最大 QPS 數目係基於在測試中達到的最高 QPS:99% 的查詢順利完成而未節流,且平均延遲維持在 1000 毫秒以下。
最大 QPS 百分比 - 在特定測試中達到的最大 QPS 的百分比。 例如,如果給定測試達到的最大 QPS 為 100,則最大 QPS 的 20% 將是 20 QPS。
延遲 - 伺服器的查詢延遲;這些數值不含往返延遲 (RTT)。 這些值都以毫秒 (ms) 為單位。
測試免責聲明
我們用來執行這些基準測試的程式碼可在 azure-search-performance-testing 存放庫取得。 值得注意的是,我們觀察到 JMeter 效能測試解決方案的 QPS 層級略低於基準測試中的數據。 這些差異可能歸因於測試樣式有所不同。 這說明了盡可能讓效能測試類似於生產工作負載的重要性。
重要
這些基準測試無法保證服務可達到特定效能等級,但您將對可根據案例而預期的效能有個概念。
如有任何問題或疑慮,請與我們連絡:azuresearch_contact@microsoft.com。
基準測試 1:電子商務搜尋
為了執行這些測試,我們使用了 CDON 生產搜尋索引的快照集,及其網站中數千個獨特的查詢。
案例詳細資料
- 文件計數:6,000,000
- 索引大小:20 GB
- 索引結構描述:廣泛的索引,共有 250 個欄位、25 個可搜尋欄位,和 200 個可面向化/可篩選欄位
- 查詢類型:全文檢索搜尋查詢,包括 Facet、篩選、排序和評分設定檔
S1 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 104 毫秒 | 35 毫秒 | 115 毫秒 | 177 毫秒 | 257 毫秒 | 738 毫秒 |
50% | 140 毫秒 | 47 毫秒 | 144 毫秒 | 241 毫秒 | 400 毫秒 | 1175 毫秒 |
80% | 239 毫秒 | 77 毫秒 | 248 毫秒 | 466 毫秒 | 763 毫秒 | 1752 毫秒 |
S2 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 56 毫秒 | 21 毫秒 | 68 毫秒 | 106 毫秒 | 132 毫秒 | 210 毫秒 |
50% | 71 毫秒 | 26 毫秒 | 83 毫秒 | 132 毫秒 | 177 毫秒 | 329 毫秒 |
80% | 140 毫秒 | 47 毫秒 | 153 毫秒 | 293 毫秒 | 452 毫秒 | 924 毫秒 |
S3 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
在此案例中我們看到,新增第二個分割區會大幅增加最大 QPS,但新增第三個分割區則會導致邊際回報遞減。 增進幅度較小,可能是因為所有資料都已提取到只有兩個分割區的 S3 作用中記憶體中。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 50 毫秒 | 20 毫秒 | 64 毫秒 | 83 毫秒 | 98 毫秒 | 160 毫秒 |
50% | 62 毫秒 | 24 毫秒 | 80 毫秒 | 107 毫秒 | 130 毫秒 | 253 毫秒 |
80% | 115 毫秒 | 38 毫秒 | 121 毫秒 | 218 毫秒 | 352 毫秒 | 828 毫秒 |
基準測試 2:文件搜尋
案例詳細資料
- 文件計數:750 萬
- 索引大小:22 GB
- 索引結構描述:23 個欄位;8 個可搜尋,10 個可篩選/可面向化
- 查詢類型:具有 Facet 和搜尋結果醒目提示的關鍵字搜尋
S1 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 67 毫秒 | 44 毫秒 | 77 毫秒 | 103 毫秒 | 126 毫秒 | 216 毫秒 |
50% | 93 毫秒 | 59 毫秒 | 110 毫秒 | 150 毫秒 | 184 毫秒 | 304 毫秒 |
80% | 150 毫秒 | 96 毫秒 | 184 毫秒 | 248 毫秒 | 297 毫秒 | 424 毫秒 |
S2 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 45 毫秒 | 31 毫秒 | 55 毫秒 | 73 毫秒 | 84 毫秒 | 109 毫秒 |
50% | 63 毫秒 | 39 毫秒 | 81 毫秒 | 106 毫秒 | 123 毫秒 | 163 毫秒 |
80% | 115 毫秒 | 73 毫秒 | 145 毫秒 | 191 毫秒 | 224 毫秒 | 291 毫秒 |
S3 效能
每秒查詢數
下圖顯示服務在一段較長的時間內可處理的最高查詢負載;以每秒查詢數目 (QPS) 表示。
查詢延遲
查詢延遲會根據服務的負載而有所不同,服務在較高的壓力下會有較高的平均查詢延遲。 下表顯示三個不同使用層級的查詢延遲的第 25、50、75、90、95 和 99 個百分位數。
最大 QPS 的百分比 | 平均延遲 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 43 毫秒 | 29 毫秒 | 53 毫秒 | 74 毫秒 | 86 毫秒 | 111 毫秒 |
50% | 65 毫秒 | 37 毫秒 | 85 毫秒 | 111 毫秒 | 128 毫秒 | 164 毫秒 |
80% | 126 毫秒 | 83 毫秒 | 162 毫秒 | 205 毫秒 | 233 毫秒 | 281 毫秒 |
重要心得
透過這些基準測試,您將可了解 Azure AI 搜尋服務所提供的效能。 您也可以了解不同層級的服務之間的差異。
這些基準測試的關鍵要點包括:
- 一般而言,S2 可處理的查詢數量至少是 S1 的四倍
- 在查詢數量相當的情況下,S2 的延遲通常比 S1 低
- 當您新增複本時,服務可處理的 QPS 通常會以線性方式擴增 (例如,如果一個複本可處理 10 QPS,則五個複本通常可處理 50 QPS)
- 服務的負載越大,平均延遲就越高
您也可以看到,不同案例下的效能可能會有很大的差異。 如果您未獲得預期的效能,請查看提升效能的秘訣。
下一步
現在您已了解效能基準測試,接下來可以深入了解如何分析 Azure AI 搜尋服務的效能,以及影響效能的重要因素有哪些。