在做性能測試平台的優化過程中，由於啟動任務相對其他測試任務比較頻繁，而目前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 _wrapper def 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 cProfile import pstats cProfile.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,並且可以知道哪些是可以優化的。
