并发极限没测过, 反正协程自己跑就挺快了, requests + 多线程大概比 httpx 协程慢个 10%, gevent 不测

Test without uvloop, 12 logical CPUs.
Windows-10-10.0.18362-SP0
3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57:15) [MSC v.1915 64 bit (AMD64)]
================================================================================
test_aiohttp(3.6.2) : 2000 / 2000 = 100.0%, cost 1.158s, 1727 qps, 100.0% standard.
test_httpx(0.11.1) : 2000 / 2000 = 100.0%, cost 3.927s, 509 qps, 29.47% standard.

Test with uvloop, 1 logical CPUs.
Linux-4.15.0-13-generic-x86_64-with-Ubuntu-18.04-bionic
3.7.3 (default, Apr 3 2019, 19:16:38)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]
================================================================================
test_aiohttp(3.6.2) : 2000 / 2000 = 100.0%, cost 0.698s, 2866 qps, 100.0% standard.
test_httpx(0.11.1) : 2000 / 2000 = 100.0%, cost 2.337s, 856 qps, 29.87% standard.

以前随手测的, 请求本地 golang 只带 net/http 的 server

@Ritter #17 是啊, 就是 patch 位置不对, 一定要在第一行要执行的代码里打, 用多了就习惯了, 三四年没碰过 gevent 了...

在 docker 里调试如果费劲, 可以用最短案例先复现一个必定发生的代码吧, 那样举例子不会暴露源码也能更清晰地找问题...

又重新看了下你报错, 我好像误解了, 实际错误应该是 gevent 在 3.6 上给 ssl 打补丁的那个常见错误

@Ritter #14 实际上就是搞一个空文件把创建 app 对象的过程单独抛出来, 网上到处都是...
```
manage 因为我六七年没用 flask 命令行去初始化也不知道里面经历的什么... 看你上面图片 config 开头就引用 app 就是个典型错误, 因为补丁要打在所有操作之前, 而 config 的第一个操作不像打补丁而是 去 handler 里 import 东西, 所以这个错误不知道你后面修了没有
```

我回复里点 py 居然报了一大堆 请不要在每一个回复中都包括外链，这看起来像是在 spamming

这论坛也不能贴代码...

呃, 提几个常识

1. 猴子补丁要加在所有文件最顶端引用, 看你这情况 config.py 明显是在 manage.py 的顶端, 所以不该在后者打, 而是在前者那里打
2. gunicorn 借用 gevent 提速来优化 socket io 的时候, 连 workers 也要换的, 具体操作一般是 gunicorn -k gevent, 也就是你在 config.py 里的 worker class 那个参数, 所以就像第一点说的, 这个文件顶部才需要打, 不需要在 manage 里显性再 patch all 一次.

所以我一般 gunicorn handle flask 的时候, 是单独开一个符合 wsgi 的 py 文件, 里面产生一个 app, 而不是用 flask 自带生成的 manage.py 来操作

PS: 实际看你的报错, 最常见于违反相互引用的问题 (昨天刚写出来一个这种错误, 虽然大部分情况下 python 做过优化来防止多次引用, 但相互依赖还是违反常识的会递归报错), 比如 A 模块里的 a 在初始化的时候依赖 B 模块的 b 的初始化, 恰恰 B 在初始化的时候又依赖了 A 里 a 的初始化, 也就产生了死锁无限递归去初始化

就这, 可以开一个 Markdown 项目放用户名, 举报链接, 脏话截图列表了, 然后直接 Github api 批量 block

@wangyzj #3 ipad 那套听说有坑, 离职以后再也没碰过这种有点法律灰色的东西... 爬的话目前最稳定还是 hook 那套, 不过养号和买老爷机有点费事, 还要定期清理那个巨大的 sqlite 就行了(动不动二三十万图片居然存到 sqlite 里...)

@Murphy0123 #5 以前也给过我这需求, 不过不是硬性需求, 让我给推了, 成本太高了, 而且微信还自维护了一套用户行为规范, 号不养大很容易被封

前年左右就放弃 web api 改走 ipad 端的方式了, 至于今年, 我选择放弃微信...

shiv 打包成一个 zip app, 然后用官网那个嵌入式绿色版的解释器做个 bat 调用就好了, 以前用过, 还挺好使

看到标题就想起

曾经在幽幽暗暗反反复复中追问
才知道平平淡淡从从容容才是真
再回首 恍然如梦 再回首 我心依旧
只有那无尽的长路伴着我

楼主也不给点代码看看到底哪的问题, 这样提问题让人很困扰啊, 只看报错的话, 不像是客户端(也就是 requests) 的问题, 反而像是你在同一个端口下开了多个 server 报的错, 没有代码也猜不了更多了

另外提 requests 并发的几个常识吧

1. 多线程并不是越多越快, 毕竟压根又用不到多核 CPU, 直接用官方建议的并发数比较合理, https://docs.python.org/zh-cn/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor , 以前默认为机器处理器的个数, 3.8 以后又建议了 min(32, os.cpu_count() + 4).

2. 如果是 Windows 操作系统, 那就更不用考虑把并发数开大了, 别说开到几千, 开到五六百可能就超了 Windows 的单进程默认最大 文件描述符(句柄) 限制而报错了, 在 GIL 的作用下, 走协程+多路复用的路子比传统多线程要合理的多.

3. 如果真想要性能, requests 比 aiohttp 慢了 4 倍, 而且还是在 Windows 上无法启用 uvloop 提速的前提下, 协程开销比线程小很多, 也快很多, aiohttp 有 Cython 加成, 也比同样是协程的 httpx 快一大截.

4. requests 的 Session 是共享连接池的一套逻辑, 速度比 requests.get 快一大截, 毕竟后者每次要开启一个新的 Session, 也就创建新的连接. PS: 就我目前测试结果来看, 是线程安全的, 没必要加无谓的锁

5. 突破默认 http 适配器连接数上限也可以用以下代码来实现

custom_adapter = HTTPAdapter(
pool_connections=n, pool_maxsize=n)
session.mount("http://", custom_adapter)
session.mount("https://", custom_adapter)

目前我是自己爬的... Github api 标准的一塌糊涂, 而且不用 FQ, 好用的一匹

3 楼已经找到问题了, 我就提一句: 当年也遇上过, 整个 Github 都成了这种 x......

re.sub(r'[^ \w]+', '_', name).strip()

@linsxiang0731 #3 呃, 我说的是它里面的会话分组功能, 也可以冻结, 不过看到 2 楼才刚知道你要的是新版本这功能

The Greate Suspender, 最有名气的了

@frostming #12 期待 new release

提几个小需求, 不是很重要那种:

1. 目前升级单个 package 的语法是什么没找到, 之前 pipenv 升级单个包的那个命令有 bug, 然而 fix 的版本没 release 到 pypi 上, 坑惨我了, 楼主作为贡献者, 知道为啥 pypi 最新版本还是 2018 那个么

2. 有清理掉当前目录 pdm 全部相关文件夹的指令么, 有时候要重建 init, 发现旧的 __pypackages__ 似乎留下了, 有时候又纯粹想清理清理

3. 有计划支持 PEP 441 那种把整个项目打包成 pyz 么, 就是 linkedin/shiv 做的那样类似的, 毕竟依赖什么的都收集好了, 单文件发布的时候更省力气, 不过好像又和 pdm 初衷不太接近

我自己套的 ga 的那个 js, 反正不用 FQ, 还帮着统计统计