【問題記錄】uwsgi部署並啓動倆個幾乎同樣的python flask web app，發現有一個app響應時間很是長

uwsgi在同一臺linux上啓動python flask web app(倆個)， 發現第一個和第二個的簡單性能測試差距很是大，差了將近一倍：

第一個結果：

Concurrency Level: 1000
Time taken for tests: 12.581 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 1090000 bytes
HTML transferred: 380000 bytes
Requests per second: 794.88 [#/sec] (mean)
Time per request: 1258.056 [ms] (mean)
Time per request: 1.258 [ms] (mean, across all concurrent requests)
Transfer rate: 84.61 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 6.0 0 21
Processing: 18 1193 218.6 1251 1306
Waiting: 18 1193 218.6 1251 1306
Total: 39 1195 213.4 1251 1306

 

第二個結果：

Concurrency Level: 1000
Time taken for tests: 3.978 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 1090000 bytes
HTML transferred: 380000 bytes
Requests per second: 2513.72 [#/sec] (mean)
Time per request: 397.817 [ms] (mean)
Time per request: 0.398 [ms] (mean, across all concurrent requests)
Transfer rate: 267.57 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 6.5 0 23
Processing: 19 376 67.8 389 435
Waiting: 19 376 67.8 389 435
Total: 42 378 62.3 390 435

 

查證緣由：

　　是由於有一個應用的設計以及代碼編寫有問題，出問題的那個app在每一個請求都會去建立一個數據庫鏈接而且在響應完成後關閉。

 

感想：

　　當時接這個代碼時候，閱讀了全部的代碼，也知道這樣寫會有性能問題，可是因爲項目剛開始，本身的半桶水也不夠去重構了，也以爲暫時這樣能撐一段時間；but，項目上線前老大讓作一個性能測試，跳入了這個坑，白費了這半天時間，後續還要去改動。

 

結論：

　　使用數據庫鏈接池，且僅在有數據庫操做的請求中獲取鏈接