【问题记录】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] receivedConnection 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] receivedConnection 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，项目上线前老大让做一个性能测试，跳入了这个坑，白费了这半天时间，后续还要去改动。
结论：
使用数据库连接池，且仅在有数据库操作的请求中获取连接
最新文章
- 学习ASP.NET Core，你必须了解无处不在的“依赖注入”
- Ubuntu下基于Nginx实现Tomcat集群负载均衡
- Django 部署
- CodeForces 163B Lemmings 二分
- 说说QQ空间SEO
- c++转换构造函数和类型转换函数
- 【Chromium中文文档】跨平台开发的约定与模式
- js 正则学习小记之匹配字符串
- Linux之定时任务补充
- 2017年编程语言排行榜Top10，第一名是？
- 高并发WEB网站优化方案
- 学习ASP.NET Core Razor 编程系列十五——文件上传功能（三）
- XIII Open Grodno SU Championship
- XII Open Cup named after E.V. Pankratiev. GP of Eastern Europe (AMPPZ-2012)
- IE浏览器兼容性调整总结技巧
- 关于eclipse调试时程序控制台不能自动打开
- Linux中磁盘mbr分区——实践篇
- mac下python2.7升级到3.6
- [转] impress.js学习
- python django 基本测试