您好,登錄后才能下訂單哦!
我們上一篇文章說到了性能測試負載模型落地時的建模方法,這里我們先就第一種也是最常用的一種方法說起:
業務場景建模主要就是說明用戶如何使用系統,因此根據系統使用的原始數據也就是日志進行分析建模是最有效最準確的方法。所謂日志就是指用戶操作系統的痕跡,根據記錄信息時的不同視角,一般分為兩類:一類視角是基于用戶,我們稱之為操作日志,這類日志主要以用戶為觀察實體,記錄用戶從登錄系統到離開系統的每一個動作;另一類視角基于系統,我們稱之為訪問日志,這類日志主要為應用系統為觀察實體,記錄系統的輸入輸出。輸入就是每一個接收到的請求信息,輸出就是該請求的響應狀態。
對應于我們之前提出的模型的概念,當我們關注的負載主要是用戶量、業務量這類數據時,我們通常使用操作日志來進行分析。
這類日志信息一般都存儲于系統的物理表中,因此大都可以通過統計SQL來進行分析,例如公司內的各個產品線,都可以使用我們自己開發的UMT小工具直接將建模需要的關鍵信息統計出來。對于公司外的產品,該方法同樣適用,因為任何一個產品的日志信息都至少包括4W1H,也就是什么用戶(WHO)在什么時間(WHEN)由哪臺機器(WHERE)通過訪問哪個功能(WHICH)做了什么事(HOW),針對每一個W或者組合進行統計,就大致可以得出我們前面所說的要獲取的三要素信息。
該分析方法的缺點就在于:對于還原用戶使用模型的準確度來說,主要依賴于系統操作日志記錄是否完整準備。
當我們關注的負載主要是PV、吞吐量這類數據時,通常是針對訪問日志來進行分析,這類日志一般都是在中間件或WEB服務器的日志文件中存儲。
這類日志記錄的數據一般都是規則的數據,所以可以很方便的使用正則對數據整理后進行統計,對于臨時統計一下數據,可以使用類似log analyzer這類的工具統計,這類開源的小工具有很多,基本原理都是一樣的;而對于一些需要長期觀察的系統,建議的方式是根據日志文件中的字段建立一張物理表,通過shell腳本將日志文件中日志記錄整理后不斷寫入到物理表中,然后在物理表中再進行分析,分析方法基本也是4W1H原則。
該分析場景的準確度高,但由于日志是基于http請求記錄的信息。因此,要建立實用度高的分析模型,需要對系統的各個頁面和功能足夠熟悉,并且要建立準備完備的元數據來建立頁面和功能的映射。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。