效能測試平台效率優化的一次經驗（python版）



在做效能測試平台的優化過程中，由於啟動任務相對其他測試任務比較頻繁，而目前30次兩個包的交叉對比(30次)測試需要耗時30分鐘整，因此打算優先對測試流程做一次優化，將測試時間消耗降低到20分鐘。

由於一開始估計樂觀，認為啟動時間，一台裝置理論上啟動頂多1s，1*2*30也就60s，加上其他開銷，5分鐘都夠了，能減少到20分鐘應該小半天就能做完了。

於是就來到了第一步：

（1）把啟動流程裡相關的sleep全部review一遍

確實有一點效果，因為有一部分sleep在啟動任務執行階段，60倍槓桿放大後很可怕，因此去掉部分sleep，居然就減少到了23分鐘了。

第二步一時想不出了，方法耦合巢狀相當多，而且適配多個版本的產品，遷一發動全身，第二步想到的就是將可疑方法監控起來

為了方便監控，增加了兩個個裝飾器來統計耗時

def

costs(fn):
start =time.time()
fn(*args, **kwargs)
print
"%s 函式cost %s 秒
" % (fn.__name__, time.time() -start)
return
defcosts_with_info(info):
def 
print
"info: 
" +info
return
costs(fn)
當方法需要監控時，則加入@costs或者@costs_with_info("some infomation")
@costs
defconfigurequickstart(self, pkg_name):
if self.config.allow_quick_start == "1"
: self.logger.info(
"disable quick start: %s
" %pkg_name)
self.disablequickstartsnapshot(pkg_name)
else
: self.logger.info(
"quick start is enabled: %s
" % pkg_name)

於是想到了android裡的traceview，traceview有方法能拿到整個呼叫棧的效能消耗，包括耗時，python應該也有這樣的方法才對，然後我找到了cprofile，於是便愉快地進入了第三步

（1）直接將入口加入監控，輸出result.prof檔案，並在log區列印出tottime（不包含子方法的耗時統計）

import

cprofile
import
pstats
cprofile.run(
'main()
', filename='
result.prof
', sort="
tottime")
p = pstats.stats('
result.prof')
p.sort_stats(
'time
').print_stats()

一部分是系統方法，一部分是自己的方法，不是很直觀，於是又找到了另乙個神器graphviz。

首先需要安裝：

sudo apt-get install graphviz

python gprof2dot.py -f pstats result.out | dot -tpng -o result.png

區域性展示如下：

這樣就可以很清晰看到各個函式具體消耗的時間了，但令我震驚的是，啟動測試中，30分鐘裡居然有95.29%的時間是在sleep！但是沒關係，因為我知道是哪個方法開始引入的sleep,並且可以知道哪些是可以優化的。

效能測試平台效率優化的一次經驗（python版）

在做效能測試平台的優化過程中，由於啟動任務相對其他測試任務比較頻繁，而目前30次兩個包的交叉對比 30次 測試需要耗時30分鐘整，因此打算優先對測試流程做一次優化，將測試時間消耗降低到20分鐘。由於一開始估計樂觀，認為啟動時間，一台裝置理論上啟動頂多1s，1 2 30也就60s，加上其他開銷，5分鐘...

記錄一次效能優化

做了這麼久開發，終於涉及到效能優化了 原因是開啟乙個頁面花了2 6秒，被提了bug 不得不說自己有點小白，嘗試了非同步執行緒和把單次的dubbo查詢優化成批量的查詢。但是這兩種嘗試都沒有宣告成功 出了問題首先要找到問題在 既然是耗時，那就要看看到底 耗時最多 這裡要說一下，因為我是改別人的 所以對業...

記錄一次效能優化

前幾天領導扔給我乙個任務讓我對某個業務系統進行效能優化，當前現狀是每秒50併發響應時間就在30s左右，之前沒有接觸過效能優化完全沒有頭緒。領導說公司買了一套dynatrace軟體可以直接用這個軟體進行分析。在測試環境壓測發現情況如下 經統計乙個介面中共列印了80多個debug級別的log，耗時巨大。...