@laminux29 全告诉了 是你自己不翻回帖

@lesismal 任务随机下发到一个节点，在同一个 aiohttp session 里面发，每个 URL 拿到结果马上发同 URL 的下一个请求，没有关注是 http 1.x 还是 2.0
有订阅机制，但是订阅延迟不止 3 秒，用不了

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

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

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

其实是某拍卖平台的自动出价系统, 需要实时监控价格有没有被超过, 高峰期最多有 9 万条链接接近截止时间, 延迟 3 秒体验影响很大的, 同行能做到实时
平台本身推送但是延迟还不止 3 秒
@locoz

@GeekGao 纯发请求消耗不了多少 CPU 和内存吧, azure 带宽至少 1Gbps, 看起来是足够了
@phrack 确实是在代码里通过全部请求收到返回-首个请求发送前时间, 精确到毫秒计算的. 从内核发出的时间要怎么看, 在服务器上抓包么?

@stimw 但是要求签 CLA 在商业化项目中是很常见的, 我只是觉得多一个步骤体验不好

没有 API 能一次性查多个商品库存

上货=>补货

@locoz 具体场景不方便公开，但差不多就是库存监控，有 90000 个商品，上货时间没办法提前知道，我们永远比同行慢 3 秒

对方套的是 akamai 的 cdn ，测试出来 azure 耗时最短

爬的是国外的站，对方的站套了 cdn 不知道是什么机房，已经选了测试出来的耗时最短的云买服务器爬了

@so1n 并发 8000 个要 3 秒多的话才能全爬完一组 8000 个，但是单请求一个耗时只有 0.15 秒
业务实时更新接近 9 万个 URL 的数据，同行不知道怎么做到的延迟不到一秒，我们用了 10 台服务器都做不到

@darksheep9527 文件名里有创建时间呀，只要知道发生问题的时间还是可以一次定位到日志文件

@ladypxy 我们产品不同时间活跃用户量差异很大，不适合按时间

@feelinglucky 已经发生过不知道多少次日志撑爆硬盘了 要不我们能跑就行的代码连压缩都不会做