Ruby on Rails, de l'évolutivité et de performance?

Question

J'ai utilisé PHP pour un certain temps maintenant et ont utilisé bien avec CodeIgniter, qui est un grand cadre. Je suis en train de créer un nouveau projet personnel et la dernière fois, j'ai été d'examiner ce qu'il faut utiliser (PHP vs ROR), j'ai utilisé PHP à cause des problèmes d'évolutivité, j'ai entendu ROR avait, surtout après la lecture de ce que le Twitter devs avait à dire à ce sujet. Est évolutivité reste un problème dans de ROR ou a-t-il eu des améliorations?

Je voudrais apprendre une nouvelle langue, et ROR semble intéressant. PHP fait le travail, mais comme tout le monde le sait, sa syntaxe et l'organisation sont moche et il se sent comme un gros hack.

Answer 1

Pour développer sur Ryan Doherty réponse un peu...

Je travaille dans un langage statiquement typé pour mon travail de jour (.NET/C#), ainsi que le Rubis que d'un côté de la chose. Avant ma journée de travail, j'ai été le principal programmeur pour un développement ruby entreprise effectuant des travaux pour le New York Times, la Syndication de service. Avant cela, j'ai travaillé en PHP (bien que long, il y a longtemps).

Je dis ça simplement pour dire ceci: j'ai connu des rails (et, plus généralement, ruby) les problèmes de performances de première main, ainsi que quelques autres alternatives. Comme dit Ryan, vous n'allez pas l'avoir mise à l'échelle automatiquement pour vous. Il faut du travail et énormément de patience pour trouver votre goulets d'étranglement.

Une grande majorité des problèmes de performances, nous avons vu d'autres et nous-mêmes avaient à faire avec la lenteur de l'exécution des requêtes dans notre couche ORM. Nous sommes allés à partir de Rails/ActiveRecord pour Rails/DataMapper et enfin de Merb/DM, à chaque itération d'obtenir plus de vitesse tout simplement parce que les structures sous-jacentes.

La mise en cache incroyables merveilles de la performance. Malheureusement, nous n'avons pas la mise en cache de nos données. Notre cache serait effectivement invalidé toutes les cinq minutes au plus. Presque tous les bits de notre site a été dynamique. Donc, si/lorsque vous ne pouvez pas le faire, peut-être que vous pouvez apprendre de notre expérience.

Nous avons eu pour la fin de sérieux affiner notre index de base de données, faire en sorte que nos requêtes n'étaient pas très stupide des choses, faire en sorte que nous n'étions pas de l'exécution de requêtes plus que ce qui était absolument nécessaire, etc. Quand je dis "très stupide des choses", je veux dire le 1 + N requête problème...

#1 query
Dog.find(:all).each do |dog|
   #N queries
   dog.owner.siblings.each do |sibling|
      #N queries per above N query!!
      sibling.pets.each do |pet|
         #Do something here
      end
   end
end

DataMapper est un excellent moyen de gérer le problème ci-dessus (il n'y sont pas de 1 + N des problèmes avec elle), mais une meilleure façon de le faire est d'utiliser votre cerveau et arrêter de faire des requêtes comme ça :D Quand vous avez besoin de performances brutes, la plupart de l'ORM couches ne sera pas facilement manipuler extrêmement requêtes personnalisées, de sorte que vous pourriez aussi bien écrire à la main.

Nous avons également fait le sens commun des choses. Nous avons acheté un costaud serveur pour la croissance de notre base de données, et l'a déplacé sur sa propre case dédiée. Nous avons également eu à faire des TONNES de données et de traitement de l'importation en permanence. Nous avons déménagé notre traitement sur sa propre boîte. Nous avons également arrêté le chargement de l'ensemble de notre flipper pile juste pour nos données utilitaires d'importation. Nous avec goût, chargé seulement de ce que nous avons absolument besoin (réduisant ainsi la charge de la mémoire!).

Si vous ne pouvez pas dire déjà... en général, quand il s'agit de ruby/rails/merb, vous avez à l'échelle de sortir, jeter le matériel sur le problème. Mais en fin de compte, le matériel est bon marché; même si c'est pas une excuse pour la mauvaise qualité de code! :D

Et même avec ces difficultés, personnellement, je n'aurais jamais lancer des projets dans un autre cadre, si je peux l'aider. Je suis en amour avec la langue, et continuellement en savoir plus à propos de tous les jours. C'est quelque chose que je n'ai pas de C#, mais C# est plus rapide.

J'aime aussi les outils open source, le faible coût pour commencer à travailler dans la langue, le faible coût pour simplement faire quelque chose là-bas et essayer de voir si c'est vendable, tout en travaillant dans une langue qui souvent peut être belle et élégante...

En fin de compte, il est tout au sujet de ce que vous voulez vivre, de respirer, de manger et de dormir dans les jours quand il s'agit de choisir votre cadre. Si vous aimez Microsoft façon de penser, aller .NET. Si vous souhaitez open source, mais encore envie de la structure, essayez de Java. Si vous voulez avoir un langage dynamique et avoir encore un peu plus de structure que le rubis, essayez de python. Et si vous voulez l'élégance, essayez de Ruby (j'ai gamin, je ne plaisante... il y en a beaucoup d'autres élégante langues qui répondent à la loi. Ne pas essayer de démarrer une guerre du feu :D)

L'enfer, toutes les essayer! J'ai tendance à être d'accord avec les réponses ci-dessus que les soucis d'optimisations début n'est-ce pas la raison pour laquelle vous devriez ou ne devriez pas choisir un cadre, mais je suis en désaccord que c'est leur seule réponse.

Donc, en bref, oui il y a des difficultés à surmonter, mais l'élégance de la langue, à mon humble avis, l'emporte de loin sur ces lacunes.

Désolé pour le roman, mais j'y ai été et à l'arrière avec des problèmes de performances. Il peut être surmonté. Donc, ne vous laissez pas vous effrayer.

Answer 2

RoR est utilisé avec beaucoup de sites énorme, mais comme avec n' importe quel langage ou d'un cadre, il faut une bonne architecture (db mise à l'échelle, la mise en cache, tuning, etc) à l'échelle d'un grand nombre d'utilisateurs.

Il y a eu quelques changements mineurs à RoR, pour le rendre plus facile à l'échelle, mais ne vous attendez pas à l'échelle comme par magie pour vous. Chaque site web possède différentes questions d'échelle, de sorte que vous aurez à faire quelques travaux à l'échelle.

Answer 3

Développer la technologie qui va donner à votre projet les meilleures chances de succès rapide de développer dans le, facile de débogage, une facilité de déploiement, de bons outils, vous savez à l'intérieur (sauf si le point est d'apprendre une nouvelle langue), etc.

Si vous obtenez des dizaines de millions de uniques par mois, vous pouvez toujours embaucher un couple de personnes et de réécrire dans une technologie différente si vous avez besoin de sous ...

... vous serez râteau-ing dans le cache (désolé, pas pu résister!!)

Answer 4

Tout d'abord, il serait peut-être plus de sens à comparer les Rails Symfony, CodeIgniter ou CakePHP, depuis Ruby on Rails est un application web cadre. Par rapport à PHP ou des frameworks PHP, Rails d'applications les avantages qu'ils sont petits, propre et lisible. PHP est parfait pour les petits, des pages personnelles (à l'origine c'était pour "Personal Home Page"), alors que Rails est plein MVC framwork qui peut être utilisé pour construire de gros sites.

Ruby on Rails n'a pas un grand problème d'évolutivité en comparaison avec les frameworks PHP. Les deux Rails et PHP à l'échelle eh bien, si vous avez seulement un nombre modéré d'utilisateurs (de 10 000 à 100 000), qui opèrent sur un même nombre d'objets. Pour quelques milliers d'utilisateurs à un classique de l'architecture monolithique être suffisant. Avec un peu de M&M (Memcached et MySQL), vous pouvez également de gérer des millions d'objets. Les M&M architecture utilise un serveur MySQL pour poignée écrit et Memcached pour gérer de lecture à haute charge. Le traditionnel structure de stockage, un seul SQL server à l'aide normalisé tables relationnelles (ou, au mieux, SQL Maître/de Lecture Multiples Esclave de l'installation), ne fonctionne plus pour les très gros sites.

Si vous avez des milliards d'utilisateurs comme Google, Twitter et Facebook, puis probablement une architecture distribuée sera mieux. Si vous voulez vraiment à l'échelle de votre application sans limite, utiliser une sorte de bon matériel de base en tant que fondation, divisez votre application en un ensemble de services, de garder chaque composant ou un service évolutif lui-même (conception de chaque composant un service extensible), et d'adapter l'architecture de votre application. Ensuite, vous devrez adapté évolutive banques de données, comme les bases de données NoSQL et les tables de hachage distribuées (Dht), vous aurez besoin sophistiqué réduire la carte les algorithmes de travailler avec eux, vous aurez à traiter avec la SOA, l'externe services, et de la messagerie. Ni PHP, ni Rails offrent une solution magique ici.

Answer 5

Qu'est-ce que se casse avec RoR est que si vous êtes dans Alexa top 100, vous n'aurez pas de problèmes d'évolutivité. Vous aurez plus de problèmes avec la stabilité sur l'hébergement mutualisé, sauf si vous pouvez presser Phusion, Passager, ou de la Mongrel.