各语言框架并发性能测试
本文通过几个简单的试验,探究在 IO 等待为瓶颈的场景下,几个典型语言框架的并发能力。以论证异步框架在此场景下的优越性。
测试模型
假设这样一种场景,我们要搭建一个 api 转发服务器,即接到用户请求后,在服务器端调用第三方 api,等待 api 返回结果后,返回 response 给我们的用户。
本文讨论的就是当第三方 api 请求时间特别长(比如 20s)时的并发性能。如下图所示:
服务器配置
试验 web 服务器配置:1C 1G
并发请求客户端配置:2C 8G
测试结果
以 3000 并发为例,进行测试,结果如下:
开发语言
框架
运行方式
并发请求数
测试结果
内存占用%
最大 CPU%
nodejs
express
直接 run
3000
无报错
9%
25%
go
iris
直接 run
3000
无报错
12%
20%
python
flask
直接 run
3000
大量报错 系统卡死
30%+
70%+
python
flask
gunicorn + gevent (1 个 worker)
3000
30% 报错
12%
60%
python
django
直接 run
3000
全部报错 系统卡死
30%+
80%+
python
django
gunicorn + gevent (1 个 worker)
3000
30% 报错
18%
65%
python
sanic
直接 run
3000
无报错
13%
35%
结论如下:
在这种特殊测试场景(瓶颈在于 IO 等待)下,nodejs、go 这些语言的原生的异步框架确实性能出色
gunicorn + gevent 虽然可以通过打 patch 的方式实现异步协程,但效果还是始终原生的好
gunicorn + gevent 可以通过增加 worker 数量,提高并发能力(上例中如果将 worker 数增加到 3 后就不会报错了)
flask、django 直接 run,会创建一个框架默认的开发 server,它是以增加线程的方式来应对并发的,众所周知线程的切换成本比协程要高得多,由此例可以看出,当 server 维护 3000 个线程时就力不从心了
sanic 这类的异步框架,是 python 最后的牌面了(针对于这种特殊测试场景)
测试代码
代码仓库地址:https://github.com/taojy123/async_test
具体如下:
express server 代码 https://github.com/taojy123/async_test/blob/master/server1/app.js
iris server 代码 https://github.com/taojy123/async_test/blob/master/server2/main.go
flask server 代码 https://github.com/taojy123/async_test/blob/master/server3/run.py
django server 代码 https://github.com/taojy123/async_test/tree/master/server5
sanic server 代码 https://github.com/taojy123/async_test/blob/master/server4/run.py
客户端并发请求代码 https://github.com/taojy123/async_test/blob/master/client.py
延迟 20s 接口代码 https://github.com/taojy123/async_test/blob/master/serverx/app.js
发表评论 (审核通过后显示评论):