持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第20天，点击查看活动详情
一、前言
团队服务器上运行着一个项目，前端为安卓和iOS实现的APP，后端采用flask框架进行开发，并且使用uwsgi进行生产环境的部署，平时基本能够稳定运行，但是由于某种原因今日的访问量激增，导致了接口超时（400）。
出现问题的请求，后端部分执行的操作大致可以归纳为两步：
- 运行算法处理数据；
- 数据埋点。
二、分析过程
①CPU资源
使用top指令可以查看各进程的CPU与内存占用，当发生异常时，CPU并不大，基本可以排除是由于算法带来的问题。
为验证结果，将算法独立运行，使用多线程的方式模拟并发状态，经过测试未发生异常结果均能正常返回且反应时间均不长，因此彻底排除算法复杂度过高导致拥塞。
②数据库连接
服务的使用的埋点数据库独立于当前主机，且由于使用的服务较多，因此数据库主机占用平时都比较大，猜测是前端部分未作异步埋点，且数据库连接速度慢导致拥塞。
对于上述猜想，临时关闭埋点，对于所有埋点请求均返回200成功，但是不进行额外操作。
修改后，仍出现异常，就算无任何处理，仅返回空值，服务也需要一分多种才能进行返回。
③uwsgi配置
由于通过top命令，uwsgi的对资源的占用率一直很低（不到20%），因此怀疑是uwsgi出现问题。
原uwsgi运行配置如下，使用了最简的启动方式。
[uwsgi]
http = :80
module = web
callable = app
enable-threads = true
thunder-lock = true
查询uwsgi配置文档，发现未编写work参数，服务为单进程单进程运行。
虽然在测试环境以及并发量较小的情况下，服务可以正常运行，但是随着并发量增大，uwsgi无法按时处理所有请求，最终导致超时。
三、解决方法
根据服务器性能进行调试，最终选择work=5并添加到uwsgi.ini配置文件后。使用多进程处理，重新运行服务后，资源的利用率达到80%上下。
同时接口的返回值能在1s内获得，且不再返回超时（400），拥塞问题解决。
