给 dalao 递女装

如果操作不变，概率是趋近 0.6 的。肯定有你没注意到的隐性影响因素没考虑到。不然结果不会这样。

@Mac 这是什么差事

卧槽，都这份上了装啥高冷啊，早点表白啊

@terrawu 的确是的。非常感谢。

@terrawu 我之前认为我的进程开的这么多，每一个开 100 的 maxsize 已经足够了，结果就是 session 提出来和不提出来没啥差别。
现在把 maxsize 提高上去，CPU 马上能跑满了。神奇。

@terrawu 有效果！现在 16 个子进程，用全局 session，maxsize 1000，能跑到 150 qps 了。非常感谢！

@lolizeppelin 之前是 8 个子进程（ 4 核 CPU ），考虑到 CPU 没压力，瓶颈在 IO 这，又开到了 16 子进程，然后能跑到 50 qps 了，再高就会出现 HttpsConnectionError 了。
另外，你确定不是同一个请求里的 session 能共用同一个长连接？

@lolizeppelin 我试过了，并没有效果。这需要多个请求用同一个 session，而 flask 不同请求之间没法用同一个 session。

我又尝试在外层弄一个全局的 session，HTTPAdapter 里把 maxsize 调到 100，但是效率更低了，超过一半的请求都超时。

多谢各位帮忙，我觉得有必要重新描述一下问题：
现在有服务 A 和服务 B，服务 A 有一部分数据库读写操作，每次都会通过 requests 访问服务 B （每次都只会访问一次，B 服务性能完全足够）
服务 A 的结构是 Flask + Gunicorn + Gevent，当 A 服务器 QPS 到 50 时，数据库访问没有压力，但会出现 requests 到服务 B 的速度变慢甚至超时。

不是 A 一次请求内多次请求 B 服务，而是每次 A 都会请求一次 B，所以设置 session 共享 tcp 连接（ keep-alive ）应该是无效的。

@aisk 我之前说的测试方法的确有问题，用 Gunicorn 开了 gevent 实际是有效的，但是当并发量稍微一大还是会出现阻塞的情况。另外我自己单独写个 py 脚本打上 monkey patch 没效的，而且在官方文档里提到用 grequests，综上让我误以为是 gevent 没生效。

所以你说的也是对的，Gunicorn+gevent 可以让 requests 变异步，但并发高了出问题应该是 terrawu 所说的原因。

@terrawu 兄弟，你所说是最贴合我的实际情况的。

多谢各位。先解释下上面的测试，我单独用 gevent 的 monkeypatch，requests 的确没效果，gevent 显示 httplib=True 已不再支持。但用 gunicorn 开 gevent 是有效的。

@aisk monkey patch 对 requests 现在还有效吗？我自己单开测试的时候还是阻塞的啊。
加了 httplib=True 会报已经不支持。

@nullcc 兄弟。。这成本有点大啊

帮顶。建议把精通 PHP 改成了解。

@maemolee 多谢~

Markdown 样例

![Markdown Doc Sample][http://7xlizz.com1.z0.glb.clouddn.com/699B4817-1284-494D-9F50-098B439BD115.png]

挽尊。←_←
想法不错，很有趣。