看 benchmark 拿阻塞的 RoR 和 Sinatra 来比，胜之不武啊~ Sinatra 有没有接 EventMachine 或者之类的非阻塞版本，更想看这之间的对决~ （不过如果是纯返回 hello world 的场景，只要还有内存，可 handle 的 request 就可以直线起飞，快慢好像已经不是那么重要了。。

一个是我们做的某个项目，需要对政府的接口做代理并封装。而这个政府的 API 接口访问奇慢，以至于出现了严重的阻塞导致了性能问题。在一台四核的机器上最后只有 20 req/s 的性能，简直是不能忍受。

你希望的非阻塞对于你说的这个引用场景来说是饮鸩止渴啊，如果服务依赖一个阻塞的点（在这里就是政府的接口），那非阻塞接收的请求越多，这个单点处理的能力就只有 20 req/s，其它接收的请求要么返回失败要么等着，如果等着，那压力全部打在阻塞的部分，有可能直接把服务拖死。我司也用完全非阻塞的 web 框架，已经碰到过几次类似的问题了，最经典的场景就是服务强依赖数据库，数据库是阻塞的，接收得请求太多，服务端倒是跑得欢了，然而结果就是直接 hang 死数据库，导致整个服务都不可用，这甚至比低 qps 更差劲。即使没 hang 死数据库，因为非阻塞模型基本都需要进行事件轮询，等待的请求多了导致每一个请求的响应时间会进一步增长，造成更大的压力。

什么场景适合完全的非阻塞？非 CPU 密集、非 IO 密集、高并发。所以绝大多数的 web 场景根本用不上非阻塞的 web 框架，我能想到的业务场景也就 IM、推送、MMORPG 游戏适合用。其它场景，比方说要经常读写数据库的，用不用说实话没什么提升，从工程层面提升数据库的性能才是最要紧的。