Python aiohttp 异步 需要同时请求同域名下 8000 个 URL（对方网站无并发限制）把结果拼接返回，要求总耗时最短， 8000 个同时发还是先发 1000 个，不等待结果，间隔 0.1 秒再发下一批快？

90000 个商品，秒级更新，意思是你们每秒都去抓取对方 90000 个页面？？？

为什么要 8000 个结果拼接之后再返回？
8000 个单独返回不是更合理吗？

uvloop 用了吗

什么业务需要拼接 8000 个页面呢

有没有可能 对手是拍卖平台的合作伙伴-根本不用爬的？

多进程+aio ，cpu 和带宽都没跑满那就单纯是响应慢了，然后自己统计排查哪个接口慢。

反正你是最后拿到结果才拼接，又不涉及到内存竞争，都拿到返回了处理以下就好了。

#26 CPU 和带宽都跑慢了那就是单纯的响应慢。

一千毫秒内 90k url 还要返回完整处理结果，经济形势不好，搞高频交易的失业出来写爬虫了？

对方不一定是直接趴页面

好多年前我也趴微博，TWTR ，写了一套自以为巨 NB 的系统，效率比市面上的都高，可以同时趴 XXXXXX 个账号的页面，当然也耗费了很多 IP

后来发现自己就是纯纯的傻。。更巧妙的方法是直接 follow XXXXXX 个 账号，每次趴 1 个页面就行。。。

你为啥实际试试呢 ?

有没有可能你请求的 host 有并行处理请求的上限？你开多点机子测呢？上代理 ip 池呢？

别人也许同机房有节点 路径比你短的多 你的最短耗时并不意味着真的是最短耗时 而且算下来你爬你对手的 比直接爬数据源要快

@cat 是这样，同行据说也是这么做的
@lambdaq 平台推送延迟不止 3 秒
@lovelylain 一批爬完马上爬下一批，没有 sleep

@drymonfidelia cpu 主频决定了内核调度速度

看你回帖你已经排除了服务端限制，那你先着手在长链接优化和并行逻辑优化上，还是没有效果的话换 golang 吧，因为没多少优化空间了(无限堆机器的话另说)，你使用了 aiohttp ，python 中的协程还是单核 cpu 调度的，你并发太多，会在某一瞬时峰值达到观测不到的瓶颈，而 golang 的强项就在协程并发

做个日志吧....
看看分配到 10 台机，每次请求返回的时长是多少，整体完成时间是多少......
先找出耗时的点。
另外确定下是不是对方根据 IP 限速，这部分可以根据上面的测试结果判断，如果每台机实际 QPS 都是 100 ，那可能对方是根据 IP 限制了 QPS ，这个时候上代理池。
1 、测试对方是否限制 QPS ；
2 、测试对方根据什么限制 QPS ？[IP/token/cookies....]
3 、如果能 100%确定对方是没限制 QPS 的话，看看时间消耗在哪里了，这个根据服务器监控和埋点的日志基本可以分析出来。
4 、如果确定对方限制 QPS ，根据限制策略进行调整，如限制单 IP 的 QPS 为 100 ，那[每 100 个地址，就用一个代理 IP] = 1 次任务。

不过说真的，并发 8000 ，不止你们去爬，这访问量挺恐怖的...
有没有一种可能，同行爬取的方式和你们不同，即对方可能一次请求返回所有，而你们没发现只能一个个爬呢？

对比一下 akamai CDN 更新数据时间，和竞争对手的数据时间。会不会对手家有别的渠道？

以及资源的 CDN 的路径是有规则的吗？也就是这 8000 个 URL 地址是怎么获取的？会不会是发现地址慢了？而不是请求资源满了。

@yuyue001 8000 个 URL 是用户提交的，在我们数据库里
akamai CDN 的数据是实时的

@markgor 平台上拍卖机器人泛滥，官方没管过，基本上是默许了 是有一次请求多个的列表 API ，但列表 API 有缓存延迟不止 3 秒，用不了