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

结论：

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