Ruby Rack并发 rack.multithread、async.callback 或两者兼而有之

注意:我使用Thin作为实现异步Rack 扩展的所有web服务器的同义词(即Rainbows！、Ebb、Puma的future 版本等等)

Q1.正确.它将响应生成(aka call)封装在EventMachine.defer { ... }中，这将导致EventMachine将其推送到其内置线程池中.

Q2.将async.callback与EM.defer结合使用实际上没有太大意义，因为它基本上也会使用线程池，最终得到类似的构造，如Q1所述.当仅将eventmachine库用于IO时，使用async.callback是有意义的.一旦以正常Rack 响应作为参数调用env['async.callback']，Thin将向客户端发送响应.

如果主体是EM::Deferrable，Thin将不会关闭连接，直到延迟成功.一个相当保守的秘密:如果你想要的不仅仅是长轮询(即在发送部分响应后保持连接打开)，你也可以直接返回EM::Deferrable作为body对象，而不必使用throw :async或-1状态码.

你猜对了.提高线程化应用程序在Rack might上的负载，否则将保持不变.在我使用Ruby 1.9.3的机器上，简单的Sinatra应用程序的性能提高了20%，在Rubinius或JRuby上运行时，性能更高，所有内核都可以利用.如果以事件方式编写应用程序，第二种方法很有用.

为了让一个无事件的应用程序利用这些机制(请参阅em synchrony或sinatra synchrony)，您可以在Rack 上施展大量魔法和黑客攻击，但这会让您陷入调试和依赖的地狱.

异步方法在应用程序中非常有意义，这些应用程序往往最好使用事件处理方法(如a web chat)来解决.但是，我不建议使用线程方法来实现长轮询，因 for each 轮询连接都会阻塞一个线程.这将给你留下大量无法处理的线程或连接.默认情况下，EM的线程池大小为20个线程，将每个进程的等待连接限制为20个.

你可以使用一个服务器， for each 传入的连接创建一个新线程，但创建线程是昂贵的(MacRuby除外，但我不会在任何生产应用程序中使用MacRuby).例如serv和net-http-server.理想情况下，您需要的是请求和线程的n:m映射.但目前还没有提供这种服务的服务器.

如果你想了解更多关于这个话题的信息:我在洛基山Ruby(以及许多其他会议)上做了一个关于这个的演讲.视频记录可以在on confreaks页找到.