
flask 实现一个 http 消息代理服务,即 客户端 A -> 代理 -> 服务器 B 。 目前方案:
请求用的 requests
目前是代理收到 A 的请求后,会等待代理请求 B 得到回复后,再把内容回复给 A 。会有等待。测试发现该方式高并发性能比较差,需要哪些优化处理?
1 chroming 2021-01-24 13:38:24 +08:00 via iPhone 主要耗时在代理等 B 的过程?用了 gunicorn+nginx 么? |
2 simple2025 2021-01-24 13:47:16 +08:00 改用 tornado 吧? |
3 wuwukai007 2021-01-24 14:20:27 +08:00 fastapi 或者 django3.1 吧 |
4 viiii 2021-01-24 14:50:13 +08:00 有高并发需求, 直接无脑 fastapi |
5 BeanYoung 2021-01-24 14:53:02 +08:00 via iPhone 这场景适合用 openresty,没有比这个性能更好的了应该 |
8 leir 2021-01-24 15:46:34 +08:00 |
10 Vegetable 2021-01-24 17:00:52 +08:00 fastapi+httpx,采用协程方案,对代码改动最小。长得和 flask+requests 差不多,性能基本就是 python 天花板了。 |
11 LeeReamond 2021-01-24 17:22:14 +08:00 via Android py 的高并发的话肯定是要上 io 复用的,flask 怎么部署都不行。fastapi 我没测试过,aiohttp 的话可以上 uvloop+prefork 部署,单机可用性能达到几万 qps,很可以了 |
12 laminux29 2021-01-24 18:28:42 +08:00 Python 的优势在于超高的开发效率,如果一定要追求运行性能,建议考虑一下 C++,或者把 Python 耗性能的部分改成 C++实现或 C++中间件。 |
13 abersheeran 2021-01-25 10:13:34 +08:00 flask 、requests 这两个库,跟高并发这个词一点关系都没有…… 你这个需求也别用 fastapi,他那个依赖注入一上,性能哗啦啦往下滑。倒不是说依赖注入不好用,关键你这个需求用不上。 @Vegetable 天花板就省省吧……它是天花板,那我写个玩意,性能是它 1.5 倍,岂不是把楼炸了? 楼上说的对,如果你会用 openresty,这个是最好的。如果执意用 Python,推荐 bottle/pyramid 。真正的 Python web 框架性能天花板。https://github.com/the-benchmarker/web-frameworks 以防有人说我信口开河,性能测试排名在此。 然后请求部分,如果你上了我说的两个框架之一,requests/httpx 随便挑一个就好了。有栈协程一开,都可以的。 |
14 sadfQED2 2021-01-25 13:59:35 +08:00 via Android @PPTX openresty 是最好的选择了,数据处理什么的不是问题,openresty+lua 你查库写业务逻辑都没问题 |
15 PPTX OP @abersheeran @sadfQED2 目前的代理消息走向:客户端 A --> 我的代理 --> 服务端 B 。 我的代理收到 A 的请求后,会等待请求 B 得到回复后,再把内容回复给 A 。 我的代理 在收到 客户端 A 的请求后,会访问 redis,找出请求 url 到服务端 url 的映射,也就是每条请求消息,服务端的 url 可能都是不同的,存在 redis 里。这个场景,用 openresty + lua 能实现吗? 感谢 |
16 abersheeran 2021-01-25 16:07:31 +08:00 @PPTX 可以。Lua 操作 redis 呗,有现成的库。 |
17 PPTX OP @abersheeran 多谢 |
18 hushao 2021-01-25 18:23:16 +08:00 tornado/aiohttp/starlette/django3 + httpx 异步请求,asgi 方式部署,其中 httpx 和 requests 的用法兼容。flask 本身就算了,确实跟并发不一条路。 重点是异步网络请求。 |