flask 实现一个 http 消息代理服务,即 客户端 A -> 代理 -> 服务器 B 。 目前方案:
请求用的 requests
目前是代理收到 A 的请求后,会等待代理请求 B 得到回复后,再把内容回复给 A 。会有等待。测试发现该方式高并发性能比较差,需要哪些优化处理?
1
chroming 2021-01-24 13:38:24 +08:00 via iPhone
主要耗时在代理等 B 的过程?用了 gunicorn+nginx 么?
|
2
chenqh 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 本身就算了,确实跟并发不一条路。
重点是异步网络请求。 |