背景： 随着业务增长，API 接口 499,502 的数量也呈现增长的趋势。当下使用的 nginx + gunicorn + flask 的框架结构看起来已经到达了瓶颈。
故探索使用 nginx + uwsgi + flask 的架构来提示性能。
名词解释：gunicorn/uwsgi都是wsgi协议（python web server gateway interface）的实现，
它们做的事情是协议转换，协议的一头是web app（如flask, django等framework的app），
另一头是web server（如apache, nginx等），gunicore/uwsgi在默认的情况下都是同步模型，
但都比通常的web framework实现得好。
使用的版本：
gunicorn==20.0.4
uWSGI==2.0.20
测试服务器信息：
CPU&内存
8核16 GiB
操作系统
Ubuntu 16.04 64位更换操作系统
实例规格
ecs.t5-c1m2.2xlarge(性能约束实例)升降配
实例规格族
ecs.t5
开始测试：
uwsgi 配置详情
# http 方式
[uwsgi]
http = :5001
chdir = /home/www/xxx/xxx/
wsgi-file = scripts/web.py
callable = app
processes = 1,4,8,16
threads = 1
# socket 方式
[uwsgi]
module = scripts.web:app
master = true
processes = 1,4,8,16
socket = hebe.sock
chmod-socket = 660
vacuum = true
die-on-term = true
gunicorn 配置详情
./ve gunicorn --preload \
--backlog 2 \
-w 1, 4, 8, 16 \
-b 10.111.1.180:8011 \
-b 127.0.0.1:8011 \
-c /home/www/xxx/xxx/scripts/gunicorn_config.py \
scripts.server:app
测试工具 wrk
`[root@jerrik /]# wrk -t12 -c100 -d30s [http://www.baidu.com ](http://www.baidu.com%20/)`
`Running 30s test @ [http://www.baidu.com](http://www.baidu.com/)`
`12 threads and 100 connections`
`Thread Stats Avg Stdev Max +/- Stdev`
`Latency 211.76ms 304.92ms 1.97s 88.17%`
`Req/Sec 72.93 68.72 797.00 90.97%`
`23725 requests in 30.05s, 347.47MB read`
`Socket errors: connect 0, read 48, write 0, timeout 50`
`Requests/sec: 789.57`
`Transfer/sec: 11.56MB`
解释说明
- 12 threads and 100 connections:
- 总共是12个线程,100个连接(不是一个线程对应一个连接)
- latency和Req/Sec:
- 代表单个线程的统计数据,latency代表延迟时间,Req/Sec代表单个线程每秒完成的请求数，他们都具有平均值, 标准偏差, 最大值, 正负一个标准差占比。一般我们来说我们主要关注平均值和最大值. 标准差如果太大说明样本本身离散程度比较高. 有可能系统性能波动很大.
- 23725 requests in 30.05s, 347.47MB read
- 在30秒之内总共有23725个请求,总共读取347.47MB的数据
- Socket errors: connect 0, read 48, write 0, timeout 50
- 总共有48个读错误,50个超时.
- Requests/sec和Transfer/sec
- 所有线程平均每秒钟完成了789.57个请求,每秒钟读取11.56MB数据量
CPU 密集型测试：
@app.route('/py.cpu')
def python_cpu():
"""
测试 cpu 性能
:return:
"""
def double_fact(x):
ans = 1
for i in range(1, x + 1):
if i % 2 == x % 2:
ans *= i
return ans
def asin(x, t):
answer = 0
for k in range(0, t + 1):
a = (double_fact(2 * k - 1) / double_fact(2 * k)) * (pow(x, 2 * k + 1) / (2 * k + 1))
print("k=%d,a=%s" % (k, a))
answer += a
return answer
app.logger.info(asin(1, 100) * 2)
return success(dict(version=sys.version))
IO 密集型测试：
@app.route("/py.io")
def python_io():
"""
测试网络 io 性能
:return:
"""
import requests
url = "https://www.idejian.com/"
requests.get(url) # 发get请求
app.logger.info(sys.version)
return success(dict(version=sys.version))
结果比较： ./wrk -t 16 -c 100 -d 10 https://xxxx.com/py.cpu
CPU 密集型API
20211217182527.jpg
结果比较： ./wrk -t 16 -c 100 -d 10 https://xxxx.com/py.io
IO 密集型API
20211217182648.jpg
结论：同步调用下，uwsgi 并没有比 gunicorn 更高性能。和预期不符，不知道是否是测量的方式有问题。 暂时不考虑使用 uwsgi ，继续优化 gunicorn
gunicorn 优化项目
- 调整进程数据为 cpu *2 + 1
- gunicorn worker_class = "eventlet"
- gunicorn preload 关掉
- gunicorn backlog 调整为 2048
在测试环境中测下来，上面的四项调整有明显的性能提升，但也带来了新的问题。
- 异步的为每个连接创建一个“绿色”线程，在处理IO机密型程序时，有明显的性能提升。
- 弊端是为每个连接创建一个“绿色”线程，在高峰期的时候，mysql 等其他有连接池的工具，不能提供足够的链接。导致程序报错。
