Il y a quelque temps, pour des raisons de performance et de scalabilité, LinkedIn a remplacé son infrastructure serveur pour les mobiles passant de Ruby on Rails à Node.js. Un ancien membre de l'équipe a réagit pour expliquer ce qu'il s'etait mal passé avec l'ancienne plateforme.
Kiran Prasad, Directeur de l’Ingénierie Mobile chez LinkedIn, a expliqué à ArsTechnica qu'ils ont eu à reconsidérer leur infrastructure serveur car, même si seulement 7 à 8% de leurs clients utilisent l'application mobile, le serveur en Ruby on Rails souffre de sévères problèmes de scalabilité.
LinkedIn a évalué 3 solutions possibles : Rails/Event Machine, Python/Twisted et Node.js. D'après Prasad, Node.js a finalement été choisi car il propose les avantages suivants :
- Meilleures performances, Node.js est plus de 20 fois plus rapide que Rails pour certains scénarios
- Utilisation de seulement 3 serveurs au lieu de 30, ce qui laisse de la place pour une croissance de 10 fois le trafic actuel
- Les ingénieurs front-end JavaScript peuvent participer au code du serveur et les deux équipes ont finalement été fusionnées en une seule
LinkedIn, qui choisit d'abandonner Rails à cause de problèmes de scalabilités, a déclenché de nombreuses réactions sur le Web. Ikan Lan, un ancien membre de l'équipe mobile de LinkedIn, a partagé sa version de l'histoire à propos des problèmes rencontrés sur l'ancienne plateforme :
"La solution que nous avions choisie était Ruby on Rails 1.2 servie par Mongrel. Souvenez vous, nous sommes en 2008, Mongrel était ce qu'il se faisait de mieux dans les technologies Ruby. Phusion Passenger n'était pas encore sorti et Mongrel était à des années lumières devant le FastCGI. Le problème de Mongrel ? Il est mono-threadé. Il était alors réputé que le coût réseau était bien plus important que l'efficacité CPU, un choix avec lequel j'étais d'accord... Nous avons déployé avec Capistrano et nous étions les premiers à utiliser nginx...
[...] Plus tard, nous avons upgradé vers Rails 2.x+ ... Oh, et nous avons également décidé d'utiliser OAuth pour l'authentification sur les iPhones. Le canard boiteux OAuth, du coup, nous avons transformé nos serveurs Rails en providers OAuth. Pourquoi nous avons utilisé ce canard boiteux ? Simple : nous ne savions pas ce que nous faisions. J'ADMETS CA."
Les serveurs dédiés aux services mobiles étaient hébergés chez Joyent, ainsi, quand une application mobile avait besoin d'une information, la requête devait voyager jusqu'à chez Joyent puis faire un nouveau voyage jusqu'au datacenter de LinkedIn où l'API principale du service se trouvait. D'après Lan :
"C'est une requête qui fait appel à plusieurs datacenters, les amis. Et elle était traitée par un serveur Rails mono-threadé (chaque requête est bloquante pendant tout le traitement) et un Mongrel qui a des fuites mémoire digne d'une passoire (c'était principalement à cause de gettext). Les serveurs Rails faisaient diverses choses comme la traduction, la transformation XML en JSON et nous avons testé quelques nouvelles fonctionnalités dédiées aux mobiles, mais en dehors de ça, il n'y avait pas grand-chose. C'était plus comme un proxy. Un proxy dont la scalabilité dépendait de combien de serveur Mongrel-mono-threadé nous exécutions. Les Mongrels, dont nous parlons affectueusement ici, prenaient souvent jusqu'à 300 Mo de RAM chacun et donc nous ne pouvions pas en lancer beaucoup."
Après avoir évoqué plusieurs problèmes, Lan a finalement admis que "v8 est vraiment rapide" mais a ajouté : "Ne comprenez pas qu'il faut forcément que vous utilisiez Node.js. Il est clairement plus adapté que Ruby on Rails pour ce que notre serveur mobile a à faire, mais ce n'est pas non plus la panacée en terme de performance. Vous êtes en train de comparer un serveur bas niveau à un framework Web full stack."
Hacker News a un long thread de réactions à cette décision d'utiliser Node.js à la place de Rails.