我們上一篇文章說到了性能測試負載模型落地時的模組化方法,這裡我們先就第一種也是最常用的一種方法說起:
業務場景模組化主要就是說明使用者如何使用系統,是以根據系統使用的原始資料也就是日志進行分析模組化是最有效最準确的方法。所謂日志就是指使用者作業系統的痕迹,根據記錄資訊時的不同視角,一般分為兩類:一類視角是基于使用者,我們稱之為記錄檔,這類日志主要以使用者為觀察實體,記錄使用者從登入系統到離開系統的每一個動作;另一類視角基于系統,我們稱之為通路日志,這類日志主要為應用系統為觀察實體,記錄系統的輸入輸出。輸入就是每一個接收到的請求資訊,輸出就是該請求的響應狀态。
對應于我們之前提出的模型的概念,當我們關注的負載主要是使用者量、業務量這類資料時,我們通常使用記錄檔來進行分析。
這類日志資訊一般都存儲于系統的實體表中,是以大都可以通過統計SQL來進行分析,例如公司内的各個産品線,都可以使用我們自己開發的UMT小工具直接将模組化需要的關鍵資訊統計出來。對于公司外的産品,該方法同樣适用,因為任何一個産品的日志資訊都至少包括4W1H,也就是什麼使用者(WHO)在什麼時間(WHEN)由哪台機器(WHERE)通過通路哪個功能(WHICH)做了什麼事(HOW),針對每一個W或者組合進行統計,就大緻可以得出我們前面所說的要擷取的三要素資訊。
該分析方法的缺點就在于:對于還原使用者使用模型的準确度來說,主要依賴于系統記錄檔記錄是否完整準備。
當我們關注的負載主要是PV、吞吐量這類資料時,通常是針對通路日志來進行分析,這類日志一般都是在中間件或WEB伺服器的日志檔案中存儲。
這類日志記錄的資料一般都是規則的資料,是以可以很友善的使用正則對資料整理後進行統計,對于臨時統計一下資料,可以使用類似log analyzer這類的工具統計,這類開源的小工具有很多,基本原理都是一樣的;而對于一些需要長期觀察的系統,建議的方式是根據日志檔案中的字段建立一張實體表,通過shell腳本将日志檔案中日志記錄整理後不斷寫入到實體表中,然後在實體表中再進行分析,分析方法基本也是4W1H原則。
該分析場景的準确度高,但由于日志是基于http請求記錄的資訊。是以,要建立實用度高的分析模型,需要對系統的各個頁面和功能足夠熟悉,并且要建立準備完備的中繼資料來建立頁面和功能的映射。