我不会把它变成Rails vs Framework X的讨论,已经有很多这样的讨论了.在认真思考我将要用于下一次部署的框架之后,我认为很难将开箱即用的问题放在一边REST REST Rails为您提供最小的工作量.这需要在Django中稍微多做一些工作,并且考虑到我主要强调应用程序的API部分,这次Rails更有意义.考虑到我编写一个包含可以访问(不仅仅是Web浏览器)的异构客户端(
iphone /
android / tablets)的应用程序的重要性,我需要能够以最小的阻力来构建RESTful API,无论我是什么框架使用.
我的问题是,Rails是否准备好处理不是Twitter大小的应用程序,但每天大约有75,000个独特的点击量？ Ruby 1.9.1真的能改进吗？根据你的要求,有很多噩梦般的故事和成功案例. Joel Spolsky(stackoverflow.com的创始人之一),believes Ruby itself is just not ready for prime time,因为它仍然比其他解释语言慢得多.我并不担心达到推特的规模(这是我希望有一天会遇到的问题),但同样的道理,我的网站每天平均有75,000个独立用户.我想知道通过决定使用Ruby 1.9.1最新的Rails(cpu占用内存占用空间)作为我的API堆栈的一部分而不是花时间实际做一些额外的工作,我会遇到什么样的扩展问题. Django构建RESTful API.正如Joel在他的文章中提到的那样,当我购买10时,我不想购买100台服务器.我很想知道为什么Rails现在已经准备好满足我的要求了.
解决方法
几个月前我们用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之外没有其他任何变化.这也意味着我们能够将每个服务器可以处理的负载量加倍.
您当然可以使用不兼容1.9的宝石,但绝大多数宝石都可以或可以与微小的变化兼容.
您肯定不会遇到75,000个唯一身份访问者的任何问题,并且单个服务器应该能够托管至少十倍于此流量级别的rails应用程序,除非您的应用程序编写得非常糟糕.
