@elonlo #17 现在直接用 uvicorn --workers 8 就可以了，不是用 zibai 部署，是用了和 zibai 一样的多进程管理器。

技术要服从需求，国内没有 TOTP 的需求。因为手机号是都有的，额外增加一个 TOTP 纯浪费人力物力，还要教育客户使用。

可能 apple 认为英文不应该上架国区，毕竟中国是一个使用中文最多的国家。

人总是喜欢把自身的问题推诿给别的东西，但实际上空洞的原因是自己。

不行就消费消费，从消费里获得社会认同和社会地位，这就是消费主义大行其道的原因。与其说是资本推动的消费主义，不如说是越来越多的人从生存还是死亡的一线脱离，不再疲于奔命就会寻找生命的意义，但生命的意义是什么？找不到自然就迷茫，迷茫就会焦虑，焦虑就需要缓解。消费正是最容易的一条路径。

原来我是太乙 https://github-immortality.vercel.app/api?username=abersheeran

你要是 for future in concurrent.futures.as_completed 那就会等到所有 future 完成，如果只是 concurrent.futures.as_completed 那就继续下一行了。

另外，future.result() 会阻塞当前线程直到 future 完成为止。

开放源代码不代表一定要给你写文档吧？我觉得真的白嫖成习惯了，升米恩斗米仇是吧。别人开源出来勤勤恳恳写文档，那就感谢他。别人把代码放出来但是不写文档，那也是他的权力。

上纲上线的，没必要。

@tonyer #12 苹果真恶心啊。

@tonyer #3 我之前是苹果全家桶，现在手机换了小米，但是耳机偶尔会连 MacBook 或者 iPad ，会自动更新吗？

remote 是这样的。所以我感觉 remote 真的需要自己社交圈大才行。

@frostming 我对追求极致性能这件事兴趣不大。这个 ODM 也是 pymongo 和 motor 都支持，我自己一般是用同步的 pymongo

@jadehare #1 你是懂广播打击的。

我的评价是：这种文章都不会好好写的人，代码也只能写成一坨屎。

你都上 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 测一下