SolrQuery性能壓測參考大緻有下面幾類特征應用搜尋壓測注意實作基本性能名額性能壓測方案模闆

一類 key-value，資料庫join搬到倒排中而已， 代表應用 很大部分應用場景

一類 區間查詢為主 代表應用 ****

一類 純文字查，不存儲，典型隻查索引傳回db的索引id資訊，代表應用 **** 一類 各種查詢涵蓋，facet、區間、group較多 典型代表 *** 如果應用場景相類似，已線上應用的性能或者曆史壓測資料具有一定的參考價值。

如果應用場景不類似，特别是有某個極端需求或者極端場景特征的話，通常需要具體測試和針對性優化。

<a></a>

性能壓測需要關注:資料量、索引結構、查詢特征、cache參數、硬碟配置，然後針對具體應用做具體壓測。

基于的覆寫測試、功能測試、場景模拟是必須的，并且場景對性能的影響非常大，場景模拟的越真實，性能測試結果

就更有參考價值。

壓測方式：

(1)線上分流，

将線上一部分請求引流到測試系統中。具體實作 可以是完整的一列作為測試對象，測試對象直接影響線上傳回資訊。

可以是線上系統之後，流量copy到測試系統中，測試系統不做資訊傳回，隻是壓測性能。

也可以是線上系統部分流量引流到測試系統，并且測試系統執行資訊傳回。

(2)線下模拟，

線下模拟對初始系統性能評估非常有幫助。線下模拟主要是模拟線上索引資料、查詢資料、配置資訊等，進行快速性能分析。

線下模拟更多資訊，請參考下面性能名額資訊。

(1)覆寫用例。在搜尋中覆寫用例越多越好，越不一樣越好，例如關鍵詞查詢，高頻、低頻、普通用詞都有，并且量盡量多。

如果覆寫的範圍非常少，或者不同類型查詢比例配置設定不合理，測出的性能也完全不一樣。例如，實際場景有區間查詢、

關鍵詞查詢、facet、group，而測試用例中各類型查詢比例設定不合理，那麼出來的結果完全不一樣。

(2)索引結構。壓測的索引結構應該就是線上索引結構，并且最好是資料規模比較大，資料越真實越好，人造資料或者少量

資料很難發現問題。

(3)查詢特征：性能壓測一般壓關鍵查詢特征。例如區間查詢為主，那麼性能測試中更突出區間查詢的用例覆寫範圍和

用例數量。

(4)cache 參數 有些應用中是配置了cache參數，也應該需要cache參數，此時需要針對不同參數值做一輪測試。

搜尋的性能最終的飛躍完全依賴cache，尤其是io瓶頸很難突破的時候，cache就是主導了。

(5)jvm參數： 搜尋是記憶體和io密集性計算，記憶體大往往性能較好，同時fgc因參數配置不合理，也對性能影響很大。

(6)何時停止加壓 除了正常的load io cpu達到一個門檻值時候，就停止加壓。對應搜尋，其他還有另外一個重要名額。

當出現較多的query逾時，或者query時間超出預計值的時候，就不應該加壓。盡管此時可能

load不是很高、cpu、io等值都沒有達到峰值，但是，query的響應時間逾時預期了。因為超預期的響應，意味者

查詢失敗，某種程度和exception等效的。建議，加壓的時候，不僅僅關注:loadcpuio，更要關注query響應時間。

任何一方面達到峰值或接近峰值，就應該停止加壓，以當時的pqs為準。

沒有統一的、唯一的性能名額，下面值給出通常情況下的性能名額參考，作為性能優化或者壓測時的期望值。

以主站的basetime=1000ms為例，按照2-8原理，

80%的請求不能超過basetime=1000ms，20%的請求控制在1.5*basetime=1500ms

平均響應時間控制在 1000ms以内。

進一步細化：

a類:0-50ms 80% |50 -100ms 10%|100-200ms 3% |200ms-500ms 3% |500-1000ms 3% | 1000ms-x 1%

b類:0-100ms 80%|100-200ms 15%|200-500ms 2% |500-1000ms 2%| 1000ms - 1%

c類:0-200ms 80%|200-500ms 15%|500-1000ms 3% |1000-1500ms 1% |1500- 1%

也即a類型 100ms内，b類型200ms内，c類型500ms内。

這一塊性能也是從querylog中提取的。

平均hits=maxdoc*0.001,總文檔數的千分之一平均命中

等于0hits=0 比例不超出5%，查詢無命中結果控制在2%以内，否則需要執行輸入提示或者查詢條件的放寬。

這裡面沒有很好的參考，看具體情況吧。千分之一命中、98%有結果，單純從數字看還是不錯的。但是不代表

topn結果品質。

這一塊性能是從querylog中提取出來。

hits 跟響應時間有什麼關系嗎

沒有什麼關系。相同hits的 響應時間不一定相等，但是當hits 非常大的時候 響應時間肯定增大

對于高頻詞的長鍊、最複雜的查詢串(多個區間+facet或者多個facet或者多個區間或者多個or等)

需要通過測試擷取長鍊時間、極端查詢串時間，這樣就可以明了逾時比例和逾時可能的情況。

這裡注意：單純的針對性測試，不一定會暴露瓶頸，而混合其他查詢一起的時候，問題就凸現了。索引，這部分

需要混合測試，也需要單獨測試。然後考慮降低查詢複雜度、優化cache、優化引擎資料結構了。

針對資料量有些大的應用，應該掌握全量一次消耗的時間和時間消耗點。

針對索引線上服務場景下，線上一次增量的資料量。進而确定增量間隔時間。時間太短，可能不停的增量，導緻

資料一緻延後。如果時間太長，導緻新資料出來也延遲。另外，時間太短，增量過大，也可能出現oom。

在分析了上面性能之後，才進入pqs測試，這樣測出的資料更豐富，次元更多。

對于大資料建構的索引，離線分析索引結構，查找高頻詞、無效詞、長尾詞，反過來優化schema結構。

以下模闆來自***同學提供，測試應用是相親項目，相關開發同學:*****

非常感謝大家細緻的建議！我做了如下計劃，請确認下目标、場景、資料是否符合需求。

1.與老版對比，重點關注新版的[查詢]性能。

跟***确認了，新版與老版的索引結構、查詢邏輯都不一樣，但是查詢的主要用到的查詢字段是一樣的，可以通過對比，看新版性能如何。

2.老版頁面逾時

模拟複雜請求的頁面查詢，關注平均響應情況，統計逾時比例，對于響應時間較長的請求，看是否可以優化

1.***搜尋 - -p0

場景1: 關鍵詞+facet+區間搜尋

場景2: 關鍵詞

場景3: 關鍵詞+facet

建議：如果本次項目不是很關注facet性能，場景2、3是否可以不用測試。

2.頁面壓測 - -p1

分銷頁面展示：帶上所有頁面查詢條件

3.測試場景參考

測試場景list：

&lt;br&gt;

場景1: 新*搜，關鍵詞

場景2: 新*搜，關鍵詞+facet

場景3: 新*搜，關鍵詞+facet+區間搜尋（正常區間）&lt;br&gt;

場景4: 新*搜，關鍵詞+facet+區間搜尋（大區間0-999999）

場景5: 老*搜，關鍵詞+facet+區間搜尋（正常區間）查詢

場景6：新*搜，***頁面展示：帶上所有頁面查詢條件

場景設計說明：場景1與2用于測試facet性能，3與4用于測試極限情況是否會逾時，3與5用于測試新老**搜的對比，6用于測試線

上逾時問題

查詢請求準備15w條，新老查詢請求從線上拉資料後，進行解析拼裝，需要項目同學進行支援。

1.老版資料可以直接從線上拉，10w資料量，盡量減少查cache的情況

2.新版資料，需要對線上資料進行解析，重新拼裝，10w資料量

注意：需要準備不同場景的資料，并進行解析，需要****的支援。

1.優先執行關鍵詞+facet+區間搜尋的性能測試，對比新老版本的性能情況，進行性能分析及調優。

2.測試****頁面，模拟最複雜的查詢方式，關注頁面性能。

項目上線時間****，***性能測試項目計劃在****号左右完成。由于準備資料及調試腳本需要1個工作日，執行測試并進行分析調優需4個工

作日。手頭上還有一個項目在并行，是以相預計如此。