我已经看到一些开发人员在用户负载增加时必须用Ruby（Java或C）之外的语言编写其rails应用程序的某些部分（后台处理，执行密集型任务）的几个参考（似乎Twitter是一个如此）。这些问题可能主要出现在Rails 1.0 -2.0时代。但是，如果确实如此，我想与运行真实生产应用程序的开发人员确认。
答案 0 :(得分：5)
根据我的经验，很少（如果有的话）需要用除Ruby之外的语言编写Rails应用程序的服务器端部分。
像Twitter这样的公司所遇到的问题远远超出了大多数网络应用程序必须处理的范围，因此为了讨论起见，应该排除这些问题。 Twitter是一个极端的异常值。
但是，在大多数非平凡的Rails应用程序中，通常需要后台作业排队和处理，尽管这些作业通常也是用Ruby编写的。
要遵守的一个好规则是，您永远不应该让用户等待，并立即返回对HTTP请求的响应，而不必不必要地占用（Ruby支持的）请求处理器。例如，如果上传大图像并且需要大量密集转换 - 这应该是异步和离线完成的。其他Web应用程序框架和语言也是如此，无论其性能如何。
如果您需要更多后台作业的性能，您可以简单地扩展处理作业的工作进程数。对于提供Rails请求也是如此 - 例如，您可以添加更多Unicorn工作进程来处理更多请求。
虽然Ruby确实比C或温暖的JVM慢得多，但它通常“足够快”。
如果您使用的是MRI Ruby，那么您应该使用Ruby 1.9.3，它至少是1.8.x系列的两倍，并且略微改进了垃圾收集。 JRuby也表现良好，每次发布都会表现得更好。
最后，现代Rails应用程序向客户端卸载了大量处理，并且通常包含比以往更多的JavaScript / CoffeeScript。他们经常对View使用更多部分AJAX更新，这导致Rails堆栈渲染所花费的时间更少，而且服务器端Ruby处理的数据更少，更轻，比4年前所见。
您的应用程序面临的最大风险与性能无关，通常是快速变化的需求以及按时交付和按预算交付的需求。任何技术选择都是如此，尽管众所周知Rails可以帮助缓解这些领域。我是从多年来使用过许多框架和语言的开发人员那里写的，包括可测量的更快的语言和堆栈，即PHP，C＃/ ASP.NET MVC。