要我说，现在这个优化是没什么办法的，等今年 4.0 之后可能就能更进一步地优化。

@fytriht 那是因为别人本身是 thunderbolt 3 ，接口兼容 usb type-c ， thunderbolt 的接口本身就是带 dp 信号的

@chairuosen jQuery 是真牛逼，你看看现在的浏览器就原生支持 jQuery 那个堪称神来之笔的 css selector(document.querySelector)，平台将库的功能收作正规军。
牛逼的东西都是在无形中的时候改变着世界，它将成为标准，而不仅仅是一时的风潮。

gevent 怎么说呢？它帮你做了很多东西，但是这些东西当你真正想动的时候就不好搞，比如若是你一个协程运行了超级久，我自己就对这个协程很无力，我无法在外部有任何方法可以终结*这一个*协程。当然你若是要做到这一步的话，可能 asyncio 可以提供更多的明确的控制精度，而且生态可能更好。
gevent 的确是一个很不错的库，哪怕现在我司都上 Python3 ，我们还是很多项目在用着它。但是也是这样发现很多坑，比如一个 patch_all 过去，有时候正常运行的程序就变奇怪了。项目中用它， monkeypatch 的边界不好控制。
还有就是提一个小技巧，若是要用 gevent 的 monkeypatch ，那么 monkeypatch 就要越早打越好。有很多污染是可通过在函数基本 import gevent 来解决的。大家可以多多尝试

@linboki 所以说嘛，在使用用户态线程时就是得注意磁盘 IO ，要不然一次调度直接上万个用户态线程挂起。自己写的代码尚可这样，若是不是自己写的代码就得重写所有底层磁盘 IO 相关函数，否则一样大暴死，因为你不知道哪个库会在库里面来一下磁盘 IO 操作。

@linboki 这就很大区别了，一个是内核可以感知，一个是内核不能感知。那么怎么调度？你用户态堵塞的时候，我内核到底要不要挂起该进程？

确实第三种太 TM 可怕了，只能用单元测试来杜绝这样的人

@gamexg 据我了解，主流的操作系统也就只有 windows 可以读写文件达到也达到异步， IO 操作请使用 windows 特有的 IOCP

uwsgi 并没有特别快， bjoern + gunicron 也很快，关键是 gunicron 的配置简单多了。使用 uwsgi 的前提是你用了很多 uwsgi stack 。若是没有特别要求，我觉得 gunicron 更好。

@murmur 公司的产品大忌就是，这个代码是某人的代码，那个代码是那人的代码，大家都只能维护自己的代码

@zwh8800 其实就是用户态线程， erlang 也有。记得 FreeBSD 也有过 M ： N 的线程模型，后来发现 bug 多于是就砍了换成 1 ： 1 。
M ： N 初看是挺好，但是真的会比 1:1 模型强吗？我是表示怀疑的，在复杂的负载下，我认为系统的调度很有可能比用户自己调度好。

@ylsc633 客户端并没有收费吧？哪怕收费的话，你也可以拿着源码自己编译一个

提另外一个思路，环境切换到 bash on windows 如何？

请问楼主拿这个程序泡多少个妹子了？

@clino ok ，那么问题来什么都要从 socket api 写起的话，那么我身为一个库的作者，为什么不依赖标准库而要用 gevent ？而且两者的效率是一样的，开发效率也是一样的。根据现在的 asyncio ，它还可以换 uvloop 来提高性能，虽然我认为都是人们在乱 benchmark 而已。

@yuyang yield ， await 跟 gevent 没有本质的差异， gevent 你觉得不用手动切换那是你 monkeypatch 了然后 gevent 将底层 socket api 全部给你换了。这样带来一个问题就是，我压根就不知道现在我用的库支不支持 gevent monkeypatch ，隐式替代会给程序带来不可控。

在我看来拿 asyncio 跟 Tornado 比都是耍流氓。 Tornado 就一个网络框架， asyncio 是一个网络库。两者要干的事情压根就不一样。 asyncio 更多是一个接口规范，虽然自带一个实现。单用 asyncio ，应用层协议就可以自动解析？不能自动解析的话，那么比什么？

@shiny 应用层目前的换算成本高罢了，毕竟地球是一个球体，地表两点的距离不是直线

@Technetiumer 感觉 coding 像是自研的，记得 coding 是 Java 写的,gitlab 是 ruby 写的,jruby 跑 gitlab 应该不太可能。

Windows 下没有 fork ，表现不一样不是很正常的吗？而且 Windows 的进程模型跟 linux 也不一样