【问题记录】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，项目上线前老大让作一个性能测试，跳入了这个坑，白费了这半天时间，后续还要去改动。

 

结论：

　　使用数据库链接池，且仅在有数据库操做的请求中获取链接