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

结论:

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

  

上一篇:UWP-ListView到底部自动加载更多数据


下一篇:python request 以json形式发送post请求的正确的姿势