debian 9 的 apt 已经支持炫酷 https-proxy 了，还可以这样弄

export http_proxy=https://<a_https_proxy>
sudo -E apt update

像这种逻辑不复杂又追求速度的话，elrang 或者 go。我的结果是，主流方案中 erlang 效果最佳。

我的程序在实现初期就打算用 go 的，不过项目组内对于 go 选型还是有些质疑的，最后一路优化下来，目前大家对 go 的无脑质疑已经不见了，会认真评估 python 和 go 了。

@woostundy 好说，本来我是打算在 #6 一击脱离的，不过后来再点开看，发现很多盆友没踩过坑就来强答，然后还吵了起来了，真是受不了。

@enomine 回帖之前看下我的场景描述，你没遇到问题，不代表我没问题。

@smallHao 我的程序后来瓶颈不在 IO 上了，是在 CPU 上。python 代码执行效率较低以及 GIL, 不换 go 无法继续优化了。

> 弄一个全局的 session，HTTPAdapter 里把 maxsize 调到 100

这个太低，调到 1000 试下，还不行的话，你的需求就用 httplib2 实现吧。

@chenqh 好了非常多，但也不能说是 python 不行。

因为我的程序需要聚合一下后端的数据，然后做一个 digest(一些哈希操作）, 这个步骤会比较吃 CPU。
后来 IO 方面的瓶颈都优化完毕后，程序的瓶颈就体现在这里了

1. python 代码效率低，太耗 CPU
2. GIL 不能用多核
3. 内存耗费也比较大。

所以优化到这一步时候，用 go 改写就很适合了，所谓性能的话，提升了几十倍吧。

不过已经被我用 go 改写了，效果好太多。

@ChangHaoWei 没有，我手写的，我情况和楼主不一样，我的类似 gateway, 需要同时请求 N 个后端 http 服务，突发比较高。用的全局 dict 存多个 httplib2.HTTP 实例，跑的很流畅。

@woostundy 你的这种情况如果没有突发的高并发数目的话，还不如增大 requests.Session 的 pool size 试下

https://stackoverflow.com/questions/18466079/can-i-change-the-connection-pool-size-for-pythons-requests-module

以针会友

最后多说一句，讨论问题谦虚一些为好，否则有人忍不住（比如我）就会跳出来开嘲讽了。

实在要用 c socket 的库也有一些奇怪的方案， 比如这个 https://github.com/douban/greenify

@gouchaoer 大兄弟，gevent 的第一准则，不要使用 c socket 的库。

@aisk 我是在售卖我的 #6 回复的优点。

楼上的大兄弟，你的代码的确不会 block，但是你测过 “并发度” 么？

requests 的 streaming 和 pool size 的机制会导致并发瓶颈，monkey patch 的并不能帮助这个问题。
而 httplib2 没有 streaming 的接口，反而能提高真的的并发。

youtube 都在尝试把 python 用 go runtime 跑了，python runtime 真是令人无语，蛤蛤。