鏈路壓測中各界面效能統計

2022-07-10 02:45:14 字數 2497 閱讀 6273

在之前的文章中很多次提到了鏈路壓測,在鏈路壓測的統計結果中,只統計了鏈路的執行的耗時和相對應的qps,但是缺乏統計鏈路中各個介面的請求耗時,特別在針對介面響應時間的變化曲線統計,今天就補上這一塊的內容。

舊文回顧:

由於沒有在效能測試框架中對鏈路壓測中的,每個http和其他協議請求的響應時間記錄,所以統計響應結果的需要對日誌進行分類統計。

這裡分享一部分日誌,日誌的格式千差萬別,在讀取日誌中關於介面響應時間的**需要使用者自己完成。需要提前將日誌檔案清空或者臨時指定其他日誌檔案,需要正確預估日誌量和log4j 2的配置,最後所有日誌都在乙個檔案中,省得麻煩。

warn-> 建立訂單號:f1615455162cxcqx

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:1181 ms, requestid:fun20210311173240xnwf

info-> 請求uri:https://****/api/public/v1/order/create,耗時:1336 ms, requestid:fun20210311173240nbir

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:853 ms, requestid:fun20210311173241jbqr

info-> 請求uri:https://****/api/public/v1/order/create,耗時:895 ms, requestid:fun20210311173241lyis

warn-> 建立訂單號:f1615455160ybage

warn-> 建立訂單號:f1615455161ia2gc

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:1163 ms, requestid:fun20210311173240anzo

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:1600 ms, requestid:fun20210311173240ssco

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:1289 ms, requestid:fun20210311173240upsb

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:35 ms, requestid:fun20210311173242qenp

info-> 請求uri:https://****/api/public/v1/order/create,耗時:44 ms, requestid:fun20210311173242lcga

warn-> 建立訂單號:f1615455162qrvq0

info-> 請求uri:https://****/api/public/v1/order/refund,耗時:40 ms, requestid:fun20210311173242fxjg

info-> 請求uri:https://****/api/public/v1/order/create,耗時:31 ms, requestid:fun20210311173242xwel

warn-> 建立訂單號:f1615455162baa6b

info-> 請求uri:https://****/api/public/v1/order/create,耗時:27 ms, requestid:fun20210311173242lnwa

warn-> 建立訂單號:f1615455162sajuw

可以看出,這裡的請求日誌除了兩個介面的響應時間以外,就是warn列印的訂單號,需要的日誌內容格式比較統一。

指令碼依然用groovy編寫,因為實在太好用了。

def lines = rwutil.readtxtfilebyline(getlongfile("link.log"), "public/v1/order", true)

def create =

def refund =

lines.each

println statisticsutil.statistics(create, "建立訂單介面", 200)

println statisticsutil.statistics(refund, "退款", 200)

這裡的執行緒數200需要自己傳參,用來生成標題的,無其他實際用途。

由於字型原因,這裡只能放圖了。

全鏈路壓測

2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度,將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...

全鏈路壓測

之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案,自己也看了很多相關的資料,這篇部落格,說說自己對全鏈路壓測的理解,以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境,模擬海量的使用者請求和資料對整個業...

聊聊效能 全鏈路壓測 overview

全鏈路壓測是保障業務穩定性,使用者體驗的重要手段,從巨集觀角度,我覺得全鏈路壓測的作用和意義可以抽象為3個 發現問題,定位和止損問題,預見問題。發現問題 如何有效識別線上問題?現有的流程能夠保證開發環節,整合環節,預發灰度,線上 由於真實的線上環境往往很複雜,經常發生的乙個問題是我們在現在測試,功能...