鉴于性能和可扩展性方面的原因，LinkedIn前段时间将其移动设施的后台从Ruby on Rails替换成了Node.js。LinkedIn团队的一位前成员根据其自身的认识， 并解释了问题的原委。

LinkedIn移动工程部门的总监对ArsTechnica说，他们必须，原因在于尽管只有7-8%的用户使用他们提供的移动应用程序，但Ruby on Rails的后台就已经陷入可扩展性问题了。

LinkedIn评估了三种可行的解决方案：Rails/Event Machine，Python/Twisted以及Node.js。按照Prasad的说法，Node.js之所以最后被选中，是因为它提供了一些好处：

• 更高的性能，在特定场景下Node.js能比Rails快20倍
• 使用3个服务器而不是30个就能应对10倍的流量增长
• 前端工程师能够进行后端代码的开发，两个团队实际上合二为一了。

LinkedIn因为可扩展性舍弃Rails的事情在网络上引起了一些反响。LinkedIn移动团队的一位成员Ikai Lan分享了在技术选择方面以及所面临的问题上的一些：

我们选择的是Ruby on Rails 1.2版本而部署技术是。别忘了，这是2008年。Mongrel是Ruby的前沿技术。还没有发布（在此很久才发布的）而Mongrel比FastCGI早了很多很多年。Mongrel的问题是什么？它是单线程的。它认为传输速度比CPU的效率更重要，这一点我认同。…我们使用部署，并且是较早使用的。…

（后来）我们升级到了Rails 2.x+ … 并且使用OAuth来对iPhone客户端进行认证。基于3-Legged OAuth，我们将Rails服务器转化成了OAuth provider。为什么使用3-legged OAuth？很简单：我们并不知道自己在做什么。我必须承认这一点。

为移动设备提供服务的服务器托管在Joyent上。所以按照Lan的说法，当移动应用需要信息时，请求要先发到Joyent上，然后再连接提供主API服务的LinkedIn数据中心：

伙计们，这是一个跨数据中心的请求。运行在单线程的Rails的服务器上（每个请求都会阻塞主程序），运行Mongrel，内存泄露得像筛子（这主 要是gettext的问题）。Rails也做过一些事情，像翻译、将XML转换成JSON，我们还在它上面测试了一些针对于移动设备的特性，但除此以外， 它并没有做太多的事情。它仅仅比代理强一点。这个代理的最大并发数取决于我们运行了多少了单线程的Mongrel服务器。每个Mongrel经常要膨胀到 300Mb的RAM，所以我们不能大量运行它。

在指出了一系列问题后，Lan最终承认“v8确实相当快”但是他还说：“不要认为在构建下一项技术方案的时候必须用node.js。在移动应用的服 务器端，它确实是比Ruby on Rails更适合，但是它并不是性能的灵丹妙药。你正在比较的是一种较低级别的服务器和一种一站式的web框架。”

关于这个使用Node.js取代Rails的决定，Hacker News上有很长的。