请教 Python 大神关于 flask 压测 rps 掉到 0
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello_world():
return "Hello, World!"
以上代码使用 wrk 压测(wrk -t2 -c100 -d10s localhost:5000/ ),第三次 rps 就会掉到 0 ,是什么原因导致的?是 GIL 锁导致的吗?
flask 性能很差,试试异步框架
5000 端口是直接 flask run 起来的服务吗?官方说明 flask run 只用于开发用途,生产用途需要用 gunicorn 直接的框架。 flask.palletsprojects.com/en/stable/deploying/
2 楼正解
加了,一样的结果,chatgpt 也问不出什么才过来问的
gunicorn 没用好,调一下 worker 数和 worker class
怎么加的,贴配置。还有环境。
gunicorn -w 4 -b 127.0.0.1:5000 hello:app
之所以提这个问题,是看了一篇文章:Python Concurrency: Threads, Processes, and asyncio Explained,他与我之前测试 python 的结果一样,随着压测 rps 降到 0
查看一下是否是有太多 time-wait 状态的连接?如果是的话设置下 tcp_tw_reuse 啥的试试?
看起来是 flask 框架的问题,django 则是正常
虽然你这个推理很有道理……但是 flask 能有啥问题呢?
from gevent.pywsgi import WSGIServer
http_server = WSGIServer((host, port), app)
http_server.serve_forever()
用这个启动
def 前面加 async 试试看
Mac 下能重现,rps 降到 3 ,甚至出现 unable to connect to localhost:5000 Can't assign requested address 。
netstat 看到 1.6 万个 TIME_WAIT 。
换个 linux 试下呢
Linux 也试了一下,没有完全降到 0 ,只有几个 timeout 应该也是 TIME_WAIT 的影响。
Linux 下 TIME_WAIT 也在涨,在 1.4 万个左右徘徊。我是开了 tcp_tw_reuse = 2 的,然后这个 wrk 也在本机跑,所以会重用,所以连续跑 rps 基本保持不变。
def 前边能随便加 async 么?调用方式都不同了
换一个端口试试呢
Can't assign requested address
是不是 REUSE 之类的限制?
应该就是 和 说的 TCP TIME_WAIT 状态的问题。
我的 Linux (默认就是 tcp_tw_reuse = 2 ) 测试不能复现。
MAC 因为默认没有开启,所以在两次压测会把客户端发起 TCP 连接的可用端口全部消耗掉,第三次压测就没有端口可以用来建立和 5000 端口的连接了。
可以这么查看客户端可用的端口
sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535
可以得到 65535 - 49152 = 16383, 16383 差不多可以用两次压测消耗完。
参考下这篇,就楼主说的问题一模一样: web.archive.org/web/20180129235834/ danielmendel.github.io/blog/2013/04/07/benchmarkers-beware-the-ephemeral-port-limit/
这里还是有问题,那就是我换成 django 或其他语言的 web 框架压力测试却是正常的,至于 linux ,我记得几年前测试也有问题
这个和 Django 没关系。可能是 Django 性能差,用不完所有的客户端连接?
和 Linux MAC 其实也没关系,就是默认参数一个是开一个是关,可能你用的发行版 tcp_tw_reuse 是 0.
简介 WireGuard 是一种通信协议和免费开源软件,可实现加密的三层隧道协议 ,其设计目标是易用性、高速性能和低攻击面。 它旨在获得比 IPsec 和 OpenVPN 这两…
视频地址: www.bilibili.com/video/BV1XbrYY4EKm/?vd_source=bdd39f2fca456f0815c8242c657e40b5 …
昨天大面积故障,今天大面积营销。不好好出来道歉、赔钱,复盘具体原因以及改进措施。只想靠糊弄,混淆视听, 敷衍了事。 cloud.tencent.com/announce/d…