[email protected]:~$

  • PUMA 实现简要分析

    之前在 绿色线程是如何提升服务器并发性能的 一文中描述了绿色线程的原理。并且讲了我的计划:使用 Discourse 来 benchmark 绿色线程对并发性能的提升。经过一番折腾后在 LightIO 下成功运行了 Discourse 的 benchmark(折腾很久后发现需要将 Discourse 使用的 hiredis gem 换成纯 ruby 实现的 redis client),但结果却是使用绿色线程和不使用时性能表现差不多。 我推测性能相差不多的原因是 Discourse benchmark 使用了 thin 服务器,thin 是个单线程服务器,当然无法发挥出 LightIO 绿色线程的威力。那么换用 Puma 呢?来看一看 Puma 源码,Puma 实现的非常简单。 从 https://github.com/puma/puma Readme 中可以大概了解 Puma 的实现方式。 Puma 分为 Single, Cluster 两种模式: Single 是单进程多线程模式,这种模式使用 ThreadPool 处理请求。...

  • 绿色线程是如何提升服务器并发性能的

    LightIO 是去年末开始写的一个库,给 Ruby 提供了低廉的绿色线程,并且可以通过 monkey patch 替代原有的 native thread。这样服务器端可以使用大量绿色线程,用较小的消耗来获得更好的并发性。经过一段时间的开发, LightIO 已经比较完善,并且 monkey patch 后可以成功和 Rails 、Puma 等共同使用。于是我开始考虑如何测试服务器使用 LightIO 后的性能,毕竟能真正的带来性能提升才有继续开发的动力和必要。 在性能测试前要考虑下绿色线程的原理,以及为什么可以带来性能提升? LightIO 通过包装 Ruby 标准库的 Fiber 来提供绿色线程(在 LightIO 中叫 Beam),并维护一个绿色线程的调度系统。 这个『调度系统』并不复杂,简单来说只有三步: 检查 Beam,如果有 Beam 可以执行则执行。 Beam 执行到 blocking 操作时,使用 nonblocking 接口替代,并挂起 Beam 检查完成的 nonblocking 操作,如果有则恢复挂起的 Beam。 从步骤中可以看出,绿色线程帮我们节省的是『blocking 操作』时的等待,遇到 blocking 操作时调度器会尽可能的调度更多的绿色线程(可以认为这就是并发性的提升)。从这点来看效果和 callback...

  • Ruby 又要添加绿色线程了 Thread::Green

    翻到了 ruby-lang 的这个 issue,Eric Wong 给 Ruby 提了一个绿色线程的 PR https://bugs.ruby-lang.org/issues/13618 总结下: Eric Wong 给 ruby 增加了可以自动调度的 fiber,暂命名为 Thread::Green。就是类似 go 的 goroutine 这样的轻量级线程 Queue, SizedQueue 等用于同步的类是可以和 Thread::Green 一起使用的。意味着现有的 WebServer 换成 Thread::Green 很简单可以迁移 Matz, ko1 等大佬纷纷拍手称赞,(说不定很快就能用上了) 之后 ruby 可以说摆脱异步编程模型了,直接起 Thread::Green 然后用 blocking IO 就可以和 node 的 callback hell 怼一怼 对‘应用级别’开发者意味着 Web Server...