还未发布过话题
  • 看 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 游戏适合用。其它场景,比方说要经常读写数据库的,用不用说实话没什么提升,从工程层面提升数据库的性能才是最要紧的。