jmeter集群下腳本日志和報告處理

jmeter支持分布式測試，在分布式模式下，由一臺調(diào)度機調(diào)度所有的執(zhí)行機（集群節(jié)點），執(zhí)行腳本時可以自由的選擇單節(jié)點執(zhí)行或者分發(fā)集群中指定或全部的機器執(zhí)行。在使用調(diào)度機客戶端分發(fā)腳本時，無論是在GUI模式還是non-GUI模式，腳本日志的收集及報告的生成都無任何問題，但是如果是使用jmeter SDK在代碼中調(diào)用客戶端大并發(fā)分發(fā)腳本到執(zhí)行機執(zhí)行，則會存在日志無法實時獲取的問題（超大jmx腳本執(zhí)行時產(chǎn)生的超大日志通過網(wǎng)絡(luò)傳輸需要時間）。

通過分析jmeter SDK的源代碼，發(fā)現(xiàn)日志的收集是異步執(zhí)行的，而在SDK中并未提供日志收集完成的通知能力，導致根據(jù)日志生成報告時經(jīng)常出錯（實際的腳本都是正常執(zhí)行完的）。分析上述問題，提供的解決方案如下：

• 腳本執(zhí)行完后，當前線程睡眠一定時間

• 暴力反射嘗試獲得日志的傳輸狀態(tài)

• 修改jmeter SDK的源代碼，在其中增加監(jiān)聽機制

• 當前線程只負責執(zhí)行腳本到結(jié)束狀態(tài)，定時收集日志并生成報告

針對以上的4種方案，分析其優(yōu)缺點：

• 日志大小無法確定，睡眠時間無法確定，而且睡眠會導致線程等待，可能會產(chǎn)生ThreadInterruptException

• jmeter SDK注釋寫的很差（基本無注釋），分析源代碼需要強大的技術(shù)能力和一定的時間，目前的時間排期不允許

• 同樣由于注釋的原因，也需要強大的技術(shù)能力和一定的時間，不過難度比第二種方式要低，也是可以產(chǎn)生最優(yōu)結(jié)果的解決方案

• 技術(shù)要求最低，實現(xiàn)容易，但是日志和報告的生成會延遲（基于定時器的周期）

在當前產(chǎn)品的需求上，其實日志和報告并不是極其敏感和實時性要求高的數(shù)據(jù)，所以最終選擇第4種方案，代碼如下：

每個十分鐘拉取距今14400秒（任務(wù)執(zhí)行超時時間，可配置啟動參數(shù)）還未獲取日志的任務(wù)并嘗試獲取日志。

因為是異步的拉取日志，所以在拉取日志之前加載一次jmeter的配置。

考慮到每一次停機維護的時間可能會很長（超過當前設(shè)置的任務(wù)超時時間），因此還需要提供一個啟動應(yīng)用時掃描任務(wù)的能力。

CommandLineRunner接口標識應(yīng)用啟動完成時執(zhí)行該接口的實現(xiàn)類，因此需要使用@Component將類的對象加入到IOC容器中。

日志拉取完成后，再處理報告，同樣的原理每個十分鐘拉取距今14400秒（任務(wù)執(zhí)行超時時間，可配置啟動參數(shù)）還未獲取日志的任務(wù)并嘗試根據(jù)日志生成報告。

同樣因為是異步生成報告，因此需要在生成報告時，加載一次jmeter的配置管理。此處也要考慮停機維護的問題，使用CommandLineRunner。

到此，jmeter日志和執(zhí)行生成的問題完美解決，每一次執(zhí)行完的任務(wù)可能會有10左右的延遲時間用來獲取日志和報告。

▲上圖顯示任務(wù)執(zhí)行時和執(zhí)行成功后，日志和報告正在生成中

作者：陳潔

其他技術(shù)文章

企業(yè)應(yīng)用運維自動化應(yīng)該如何設(shè)計？

域內(nèi)計算機本地管理員密碼管理

騰訊PaaS平臺 | 主機名設(shè)置錯誤怎么辦？

Redis持久化介紹

4大步驟節(jié)省30%浪費，優(yōu)化企業(yè)上云成本從了解云開始！