qa 容器數量太高,可能的緣由有 api 請求的不合理調用,api 自己的性能問題等,目前的問題難以定位,因此準備出一個 qa 的 profile 分析資源消耗。python
可視化的形式查看總體 http server 的響應時間佔比,定位大頭優先消除。git
python 系的 profile 工具總體上是在太少,cprofile 用起來有些蛋疼,找了半天決定用 nylas 以前的一個 demo。github
這個工具須要 server 端是 gevent,號稱不用 gevent 也能用,不過須要改代碼。api
profile 工具,此工具採用unix singal 的方式定時採集 frame python 的棧信息,須要 hack 到生成代碼,而且須要啓動一個採集進程,因爲 github 給出的應該是個 demo,可視化的 server 目前長時間採集會有問題(採集一段時間後數據過大,頁面卡頓,可是原服務的響應 彷佛不受影響)curl
另外,原項目中的代碼須要 python 編譯時作一些事情,我 fork 了一份作了一點修改。具體操做見 README工具
https://github.com/duoduo369/...性能
我決定仍是從 README 貼過來url
test.sh 腳本的內容就是一波 curl 請求,每秒執行一次,跑個一小時好了,再大 demo 的 http 可視化工具可能卡。spa
git clone 這個項目 cd 到項目目錄 pip install -e . 將 stacksampler.py 複製到項目目錄,在按照 readme 中代碼修改的方式修改對應代碼 項目啓動後執行 python -m stackcollector.collector --host localhost --ports 16384 --interval 60 寫一個批量請求腳本 test.sh 每秒執行 watch -n1 test.sh 可視化工具 python -m stackcollector.visualizer --port 5555 若是項目所在機器沒法經過5555端口訪問,將 /var/lib/stackcollector 下的全部文件複製到能夠訪問機器訪問
就拿 demo 中的這張圖來看,須要橫着看+豎着看,每一行相加,每一起(假設爲 A)垂直上面一格全部小塊相加等於這一塊(A)。因此找面積最大的追蹤查看便可。unix