协程仅使用于类似爬虫或服务这种持续性 io 密集的程序，其他平砍算法可以解决的事情用协程就是增加心智负担。

3.75 ，3.8 还有一些库跟不上。

start_response(status, list(response.header.items())) 写成 start_response(status, [*response.header.items()])估计就没啥问题了。

方括号里面没加星号吧，加星号没见过出啥问题，除非直接上列表解析式才不用加星号，list(iterator)和[*iterator]没遇到过啥不等价问题，后者还快些，但 dict(kwargs)和{**kwargs}就不太一样，前者可以解析子元素长度为 2 的可迭代对象，后者不行。

我佛了，复习了一下文档，直接 threading.Timer 创建任务再 start 就完事了，最直接简单，线程级异步非阻塞，主进程主线程干啥都不影响，时间一到就会开始响应，不怕影响 gil 不开新进程也无妨。


https://docs.python.org/zh-cn/3/library/threading.html#timer-objects

浏览器兼容性是真的天坑

搞一个定容的 queue 队列，get 拿任务推到工厂也可以。

@ruanimal 过完了一遍才测性能的，web 框架大体都是相通的，过一遍文档了解 API 的存缺情况就差不多了，而且一般也不会拿纯 win 做生产环境，这种问题在框架里一般也很难碰上。

非阻塞的等待，如果不想借助第三方库，最起码也得开个新进程独立等待。

对于小水管来说，能压缩的压缩，能缓存的缓存，能外链的外链。

确认了一下，uvicorn 在参数设置里可以把 loop 设置为 uvloop 和 iocp，不过这两个选项在 windows 里都不支持，只支持 auto 的 asyncio。

@roundgis 我也不是想当伸手党，不过重新编译 cpython 这真不太懂，也找不到清晰的教程，select 模块我也找不到在 python 根目录的对应文件，怕乱搞搞崩了。。

@black11black 不过我之前说的确实也不对，grequests 的发送时间统计里包括了所有 request 对象的构建，request 发送接受，对返回内容解析几个过程，并不算是实质从第一个对象发出到最后一个对象发出的时间。

@roundgis FD_SETSIZE 怎么改啊，大佬明示。

@black11black 不是，不推荐归不推荐，grequests 就是单纯的 gevent+request 的封装，并发爬虫几行写完了就是图个方便，协程是原理，但用 grequests 根本不需要懂协程，而且印象中是 3.5 之前就有了。单独 request 发送回收数据是需要解析时间解析的，从数据返回到数据解析成 request 对象也是需要时间的，是需要占用 GIL 资源的，切协程这个时间在解析数据这里是可以忽略不计的，但最后接收数据的时候阻塞的，如果任意一个请求的响应变慢或超时，整体的统计时间也会大幅增加。
我这里 win10 开线程的应该是不到 1ms 左右，协程应该也是几十微妙。
grequests 的核心代码就是一行 grequests.map(request_list)，计时函数只能放在这行代码的前后，实质统计到的是所有请求完整生命周期的时间。

@black11black grequests 的问题应该是解析数据占用了线程资源导致的效率瓶颈吧

@black11black 没懂，grequests 用的 gevent 应该和之后的官方协程算另一套体系吧。。

@black11black 嗯，说的有道理，还是 Linux 做服务稳定，遇到问题也好解决。

@Qzier 没事了没事，是我搞错了，还是可以的，我傻-逼*2