ruby-on-rails - Ruby 1.9.1 真的准备好并更快地部署新的 Rails 了吗？

Question

我不打算将其加入 Rails 与 Framework X 的讨论中，已经有很多这样的讨论了。在认真考虑我将在下一次部署中使用什么框架之后，我决定很难放弃开箱即用的 REST 曝光 Rails 为您提供最少的工作。这需要在 Django 中做更多的工作，考虑到我主要强调应用程序的 API 部分，这次 Rails 更有意义。考虑到编写一个包含可以访问(不仅仅是网络浏览器)的异构客户端(iphone/android/平板电脑)的应用程序对我来说是多么重要，我需要能够构建 RESTful API，而无论我使用的是什么框架，我都需要能够以最小的阻力构建它使用。

我的问题是，Rails 是否准备好处理不是 Twitter 大小的应用程序，而是处理每天大约 75,000 次独立点击的应用程序？ Ruby 1.9.1 真的改进了吗？有很多噩梦故事和同样多的成功故事，这取决于你问的是谁。 Joel Spolsky(stackoverflow.com 的创始人之一)，believes Ruby itself is just not ready for prime time因为它仍然比其他解释性语言慢得多。我并不担心达到 Twitter 的规模(这是我希望有一天会遇到的问题)，但出于同样的原因，我确实拥有一个平均每天有 75,000 名独立用户的网站。我想知道如果我决定使用 Ruby 1.9.1 + 最新的 Rails(CPU 成本 + 内存占用)作为我的 API 堆栈的一部分，而不是花时间实际做一些额外的事情，我会遇到什么样的扩展问题在 Django 中工作以构建 RESTful API。正如 Joel 在他的文章中提到的，我可以购买 10 台服务器，但我不想购买 100 台。我很想知道为什么 Rails 现在已经准备好满足我的要求。

Answer 1

我们在几个月前试用了 1.9，速度的提升给我们留下了深刻的印象，我们几乎立即开始迁移到它的过程。唯一运行不顺畅的库是 Facebooker，我们的一位开发人员能够在几天内对其进行修补(该插件现在完全兼容 1.9)，以及我们能够轻松切换的 VPim(iCalendar 库)更新的 RiCal 插件。

Rails 2.3 完全可以在 1.9 上运行，根据我们的经验，请求时间缩短了 60% 以上。我们的集成测试也获得了同样的好处。我们有 1200 个测试工具需要 300 秒才能运行，现在只需要 110 秒，除了从 Ruby 1.8.7 切换到 Ruby 1.9.1 之外没有其他变化。这也意味着我们能够将每台服务器可以处理的负载量增加一倍。

当然有可能您使用的 gem 与 1.9 不兼容，但其中绝大多数是或可以通过微小的更改兼容。

您绝对不会遇到 75,000 个唯一身份访问者的任何问题，并且单台服务器应该能够托管具有至少十倍流量水平的 Rails 应用程序，除非您的应用程序编写得非常糟糕。