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

標籤：自己   任務   color   cost   ==   耦合   gprof   lan   oid   

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

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

於是就來到了第一步：

1.review代碼流程

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

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

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

 

2.將可疑方法的耗時監控起來

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

def costs(fn):    def _wrapper(*args, **kwargs):        start = time.time()        fn(*args, **kwargs)        print "%s 函數cost %s 秒" % (fn.__name__, time.time() - start)    return _wrapperdef costs_with_info(info):    def _wrapper(fn):        print "info: " + info        return costs(fn)    return _wrapper

當方法需要監控時，則加入@costs或者@costs_with_info("some infomation")

    @costs    def configureQuickStart(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，於是便愉快地進入了第三步

3.使用cProfile進行分析

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

import cProfileimport pstatscProfile.run(‘main()‘, filename=‘result.prof‘, sort="tottime")p = pstats.Stats(‘result.prof‘)p.sort_stats(‘time‘).print_stats()

log區列印出的日誌如下

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

首先需要安裝：

sudo apt-get install graphviz

然後下載Gprof2Dot，接著運行

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

終於我得到了一張啟動測試的方法耗時統計圖

局部展示如下：

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

 

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