Ruby on Rails不能很好地执行多线程请求响应，或者至少ActiveRecord不能做到。

创建Web应用程序时，只有一个活动同时处于活动状态的请求-响应这个概念很麻烦，它会分派需要很长时间才能完成的shell命令。

我想要我们对这些设置的一些看法吗？ Rails可能不适用于某些应用程序吗？

此外，关于Ruby on Rails的并发性的当前状况如何？最佳做法是什么？有缺点的解决方法吗？

解决方案

Rails当前不处理单个MRI(Matz Ruby解释器)Ruby进程中的并发请求。每个请求基本上都包裹有一个巨大的互斥量。使即将发布的Rails 2.2具有线程安全性已经做了很多工作，但是在Ruby 1.8x下运行时，我们将不会从中获得很多好处。我不能评论Ruby 1.9是否会有所不同，因为我不太熟悉它，但我可能没有想到。

在这方面确实非常有前途的领域是使用JRuby运行Rails，因为JVM被公认为擅长多线程。 Sun Microsystems的Arun Gupta最近在RailsConf Europe上提供了有关此设置的一些有趣的性能数据。

如果在外壳上运行的内容对于呈现页面而言不是必需的(例如，我们仅触发维护任务或者其他任务)，则应将其作为后台进程启动。检查八哥和工作。

如果这不适用于情况，则必须确保运行应用服务器的多个实例。传统上，人们会启动多个Mongrel实例。但是，现在我要说的是，进行可靠设置的最简单方法是使用Phusion Passenger。它是一个Apache模块，可让我们轻松指定要运行的应用服务器的实例数(最小和最大)。其余的由乘客完成。而且，如果我没记错的话，它不会执行愚蠢的循环调度请求。我认为这取决于可用性。

Matz的Ruby 1.8使用绿色线程，而Matz的Ruby 1.9将使用本地O / S线程。 Ruby 1.8的其他实现(例如JRuby和IronRuby)使用本机O / S线程。 YARV(又是另一个Ruby VM的缩写)也使用本机O / S线程，但具有全局解释器锁以确保在任何给定时间仅执行一个Ruby线程。

Ruby 1.9添加了轻量级的Fibers：

http://www.infoq.com/news/2007/08/ruby-1-9-fibers

Neverblock允许非阻塞功能，而无需修改编写程序的方式。这确实是一个令人兴奋的项目，并且被移植到Ruby 1.8.x(依赖Ruby 1.9的光纤)上。它与PostgreSQL和MySQL一起执行非阻塞查询。基准太疯狂了...