Je suppose que cette question a été posée beaucoup autour. Je sais Je ne veux pas savoir quels cadres sont meilleurs.
Quelle est la différence de coût des rails à l'échelle vs autres cadres (PHP, Python) en supposant une grande application avec 1 million de visites par mois?
C'est quelque chose que je vous demande beaucoup. Je peux expliquer aux gens que "les rails rendent assez bien" mais à long terme, quels sont les économies?
Si quelqu'un peut fournir des mesures, ce serait génial.
3 Réponses :
Un facteur majeur dans celui-ci est que l'accès à la base de données n'est pas affecté par le choix du framework. Quelle que soit la approche que vous prenez, vous mettez probablement des données dans une base de données relationnelle. Ensuite, la question est de savoir quelle efficacité vous pouvez obtenir les données de la base de données. Cela dépend principalement des RDBMS (Oracle vs postgres contre MySQL) et non sur le cadre - sauf que certaines bibliothèques de mappage de données peuvent utiliser une utilisation inefficace de SQL.
Pour le paramètre pur "Nombre de visites", la question est vraiment la vitesse de votre système de modèles HTML. La question est donc la suivante: combien de pages pouvez-vous rendre par seconde? Je ferais cela les métriques principales pour déterminer la meilleure taille d'un système.
Bien sûr, différentes pages peuvent avoir des coûts différents; Pour certains, vous pouvez utiliser la mise en cache, mais pas pour les autres. Ainsi, dans la mesure de l'évolutivité, diviser vos 1 million de visites dans des pages bon marché et coûteuses et mesurez-les séparément. Ensemble, ils devraient donner une bonne estimation de la charge que votre système peut prendre (ou le nombre de systèmes dont vous avez besoin pour satisfaire la demande).
Il y a aussi la question de l'utilisation de la mémoire. Si vous avez les données sur SQL, cela ne devrait pas avoir d'importance - mais avec la mise en cache, vous devrez peut-être également envisager une évolutivité WRT. Utilisation de la mémoire principale.
IMHO, je ne pense pas que le coût de la mise à l'échelle va être différent entre ces trois, car aucun d'entre eux n'a de "piles d'évolutivité" incluses. Je ne vois tout simplement pas d'énormes différences architecturales entre ces trois choix qui causeraient une différence significative de la mise à l'échelle.
En d'autres termes, votre architecture d'application va dominer la manière dont l'application échoue quelles que soient les trois langues.
Si vous avez besoin de la mise en cache de mémoire, vous allez au moins utiliser Memcached (ou quelque chose de similaire qui s'interfacera avec les trois langues). Peut-être que vous aidez votre évolutivité à l'aide de NGinx pour servir directement de Memcache, mais cela ne va évidemment pas changer les performances de PHP / Perl / Python / Ruby.
Si vous utilisez MySQL ou PostgreSQL, vous devez toujours concevoir votre base de données correctement pour la mise à l'échelle quel que soit votre langage d'application, et tout outil que vous utilisez pour commencer la clustering / miroir va être en dehors de votre application.
Je pense en termes d'utilisation de la mémoire Python (avec mod_wsgi Daemon Mode) et Ruby (Enterprise Ruby avec passager / Mod_Rack) a des empreintes de pas décentes au moins comparables à PHP sous FCGI et probablement mieux que PHP sous MOD_PHP (c.-à-d. PHP APACHE MPM PREFORK + PHP dans tous les processus Apache craint beaucoup de mémoire).
Si cette question pourrait être intéressante, c'est essayer de comparer ces 3 langues par rapport à quelque chose comme Erlang où vous (soi-disant) avoir une évolutivité intégrée bon marché automatiquement dans tous les processus Erlang, mais même alors vous aurez un goulot d'étranglement de la base de données RDBMS à moins que votre application convient parfaitement à l'une des façons de faire des choses de base de données Erlang, par exemple Couchdb.
Malheureusement, je ne connais pas aucune comparaison de coûts des rails, PHP et Django. Mais je connais une comparaison des coûts de certains cadres Web Java: printemps (9K $), guichet (59k $), GWT (6k $) et JSF (49k $).
Vous avez la conférence d'origine ici:
là, vous avez un message à ce sujet (plus court):
http://blog.websitesframeworks.com/2013/03 / Cray-Frameworks-Benchmarks-192 /
Si vous voulez essayer d'allumer ce coût. Vous pouvez traverser ces données avec le Bencharmk proposé par TechEMPower:
http://www.techempower.com/benchmarks/
Donc, si vous savez que le printemps est assez bon marché, comparez Wicket et Django / Rails ont pire des marques de référence que le guichet et le printemps, cela signifie probablement qu'ils représenteront un coût plus élevé.
J'espère que cela aide.
Je suis un peu curieux aussi mais je doute vraiment qu'il y ait une réponse concrète à cette question. Il y a trop de variables. Conception de site, valeur du temps de programmeur par rapport à l'heure de la machine, etc. Je pense qu'il existe des exemples de grands sites pour la plupart des plates-formes,