你都上 V2EX 了应该有 tg 账号，我觉得你这个场景 tg bot 更适合。

冲突是大势已成，不以任何人的意志而改变。至于会不会战争升级看接下来搅动世界风云的那些人会怎么做了，现在有原子弹悬在他们头上，所以我个人认为升级的可能性不像二战那时候那么大。

局部冲突是无可避免的。

@abersheeran #20 查到了，gunicorn 一开 gevent ，连 http 都不自己处理了，全丢给 gevent ，gunicorn 就只管进程。zibai 的用法是只用 gevent monkey patch 。gevent.wsgi 在 Linux 上比 zibai.h11 快的原因还得再查查。

@hutoer #15

找了一台低配 Linux 服务器跑测试，我发现 -t 8 -c 40 吃不满单核 CPU ，换了一个更高的参数跑。并发更大的是 gunicorn+gevent

但是看这个数据来说，zibai 的平均请求耗时明明更短，方差更小、最大值也更小。总体并发不知道为什么还没 gunicorn 高，我再深入研究一下。可能 gunicorn 对 Linux 做了针对性优化，毕竟我放在 GitHub 上的 benchmark 来自一台 MacBook ，而那个结果是反过来的，zibai 远高于 gunicorn 。

./wrk -t 16 -c 160 -d 1000 http://127.0.0.1:8000
Running 17m test @ http://127.0.0.1:8000
16 threads and 160 connections
^C Thread Stats Avg Stdev Max +/- Stdev
Latency 200.00ms 263.38ms 1.47s 81.44%
Req/Sec 715.51 0.98k 6.19k 86.00%
254899 requests in 46.36s, 41.57MB read
Requests/sec: 5498.37
Transfer/sec: 0.90MB

./wrk -t 16 -c 160 -d 1000 http://127.0.0.1:8000
Running 17m test @ http://127.0.0.1:8000
16 threads and 160 connections
^C Thread Stats Avg Stdev Max +/- Stdev
Latency 52.27ms 9.08ms 198.67ms 88.68%
Req/Sec 191.78 23.24 262.00 79.09%
90721 requests in 29.83s, 9.18MB read
Requests/sec: 3041.02
Transfer/sec: 315.20KB

@hutoer #18 那有点怪了，我一会用一个低配 Linux 测一下

@hutoer #15 https://github.com/abersheeran/zibai/blob/main/benchmark.md GitHub 上我的测试结果和你这个差别有点大

@hutoer #15 我看 gunicorn 你开 gevent 了，你装 zibai 的时候带上 gevent 了吗？看启动日志，里面会显示是否启用了 gevent 。

@chinesehuazhou #2 好，谢谢。

@founddev #13 ASGI 有 uvicorn ，我都在维护 uvicorn 了也没必要新开一个项目来对着干。兹白主要解决的就是现有 WSGI 服务器的一些痛点。

@shinession #10 速来试试 https://kui.aber.sh/wsgi/ 。对于代码能力良莠不齐的团队来说，同步代码要比异步代码更好。新手用 asyncio ，确实是会经常写出来阻塞 loop 的程序。gevent 可以低成本甚至零成本提高同步代码的并发能力，这一点远比 asyncio 强。

居然看到我前几天发的兹白了，哈哈哈哈。

虽然我天天骂苹果，但是不得不说你这个需求还是 MacBook Air m1 最香，因为看你这个描述，刚需是续航、轻薄。跟我的需求差不多，实测体验还不错。前端工具链在 macOS 上也比较齐全。

@shinession 同步+gevent 生态还是比较无敌的，kui.wsgi 用来跑模型比 fastapi 香多了。

@shinession #3
@imzcg2 #5

fastapi 用的 ASGI ，还是用 uvicorn 启动吧。兹白好用的几个特性，一部分已经在 PR 里等合并，一部分正在提交到 uvicorn 的路上。如果用 flask 、django 之类的，再考虑用兹白。

别人有更好的 PR 我一般不会提交重复的。虽然我造的轮子多，但都是别人满足不了我的需求或者我觉得别人写的太烂才写的。但凡有一个凑合能用的，我都不会自己写。

@nullboy #21 哈哈哈，上午急着去开会写的，可能比较乱。本来也不是正式推广什么的，随便写写了，大家也随便看看不用太深究这帖子说的专业方向的内容。

主要是分享一下我的喜悦，以及对 tiangolo 的感谢。这一部分应该是表达清楚了的。

@anoyi #17 bottle 或者 django 都是有缓存的，kui 也参考了他们的设计做了缓存。Starlette/fastapi 不能解决它主要是因为，他们想把每个 Route 都做成独立的 ASGI 服务，要兼顾 ASGI 标准，就很难做到缓存 Request Body 。我上面提到的几个框架，都没有这么设计，所以可以做自己的缓存。

我个人觉得 Starlette 这么设计是可以的，baize 也大量参考了它的设计，这么做了。但是 fastapi 基于 Starlette 做生产级框架，那不应该让开发人员接触到这么底层的东西。

@winterbells #12 我用了好多年，前一些时候确实出现这个问题了，我就下了 QQ 邮箱客户端解决。最近我从 iPhone 换到 xiaomi ，偶然发现，只要把 QQ 邮箱那个服务取消关注，再重新关注，新邮件就会继续通知了。我估计是他们服务更新没有处理旧数据导致的。

sanic 除了性能以外，没有能彻底击败 flask 的地方。我以前也使用过。而且初代代码确实劝退了很多用户。