Pourquoi Symfony2 fonctionne-t-il si mal dans les benchmarks et est-ce important?
Mes collègues et moi sommes en train de choisir un framework web pour développer un site web à fort trafic. Nous sommes vraiment bons avec node.js + express et php + symfony2. Les deux sont d'excellents frameworks, mais nous sommes un peu préoccupés par Symfony2 car il semble être surpassé par la plupart des frameworks Web.
Voici les benchmarks qui le prouvent: http://www.techempower.com/benchmarks/
Pour cette raison, nous utiliserons probablement node.js + express, mais je me demande toujours pourquoi Symfony2 fonctionne si mal dans les benchmarks.
En fin de compte, tout revient à corriger la gestion du cache ...
symfony ou PHP en général IS plus lent que les autres langages ou frameworks) vous fournissant ainsi les outils pour créer des applications Web riches, sécurisées et testables très rapidement.
Si vous utilisez un proxy inverse comme Vernis et [~ # ~] esi [~ # ~] (côté Edge inclus) et finissez par servir les parties de vos modèles dont vous avez vraiment besoin d'avoir mis à jour via symfony. vous aurez une expérience incroyablement rapide.
De plus, si vous utilisez un cache d'opcode comme [~ # ~] apc [~ # ~] et une base de données optimisée un utilisateur humain ne remarquera pas réellement la différence de quelques ms dans une application réelle.
Selon la demande, je vais plonger un peu plus profondément et vous donner quelques éléments de réflexion supplémentaires.
Mise en cache et performances
Avec des services cloud (s3, ec2, gae, ...) à peu de frais associés à des équilibreurs de charge, un approvisionnement facile (chef, marionnette, ...) et tous ces trucs géniaux disponibles, il est devenu facile et abordable même pour les petites entreprises pour exécuter et gérer des données volumineuses et/ou des applications à fort trafic.
Plus de stockage signifie plus d'espace pour le cache - plus de puissance de calcul signifie un réchauffement du cache plus rapide.
ce que vous entendrez souvent si les gens parlent de php ou de performance du framework:
- facebook fonctionne avec php
- youp ** n a été développé avec symfony
- ...
Alors pourquoi ces sites ne tombent-ils pas complètement en panne? Parce que leurs routines de mise en cache sont intelligentes.
Saviez-vous par exemple ce que fait Facebook si vous écrivez une mise à jour de statut?
Il ne l'enregistre pas directement dans une table de base de données avec toutes vos mises à jour de statut et si un ami visite son flux, tous les statuts de tous ses amis sont extraits de la base de données avant d'être servis.
facebook écrit votre statut dans tous les flux d'actualités de vos amis et commence à réchauffer leur cache. Maintenant, tous les flux sont en cours de préparation et chaque fois qu'un de vos amis visite son flux, il recevra une version en cache; instantanément sans presque aucune exécution de code. Le flux n'affichera votre statut nouvellement créé que lorsque le réchauffement du cache sera terminé. on parle de ms ici ...
Qu'est-ce que cela nous dit? Dans les applications modernes très fréquentées, presque tout est servi à partir du cache et l'utilisateur ne remarquera pas si le calcul réel de la page a pris 1 ms ou 5 secondes.
Dans un scénario "réel", l'utilisateur final ne remarquera aucune différence de demande/seconde entre les cadres. Même avec des trucs simples comme la micro-mise en cache, votre blog hébergé vps ne peut pas disparaître instantanément une fois que vous l'avez fait sur la page de destination de hackernews.
En fin de compte, la chose la plus importante est ... mon cadre fournit-il les outils, la documentation et les tutoriels et exemples ... pour que tout cela soit rapide et facile. symfony fait pour moi!
Si vous êtes coincé ... combien de personnes sont désireuses et capables de répondre à vos questions liées aux performances? Combien d'applications réelles ont déjà été ou seront créées dans un proche avenir avec ce framework?
vous choisissez une communauté en choisissant un framework!
... ok c'est pour la partie est-ce important ... maintenant revenons à ces repères :)
Repères et configurations
Sur toutes ces couleurs brillantes et ces graphiques fantaisistes dans le benchmark, vous manquez facilement le fait qu'il n'y a qu'une seule configuration (serveur Web, base de données, ...) testée avec chacun de ces cadres alors que vous pouvez avoir une grande variété de configurations pour chacun d'eux .
Exemple: au lieu d'utiliser symfony2 + doctrineORM + mysql, vous pouvez également utiliser symfony + doctrineODM + MongoDB.
MySQL ... MongoDB ... Bases de données relationnelles ... Bases de données NoSQL ... ORM ... micro ORM ... SQL brut ... tous mélangés dans ces configurations ------> pommes et oranges.
Repères et optimisation
Un problème commun avec presque tous les benchmarks - même ceux qui ne comparent que les frameworks php - trouvés sur le web et également ces "benchmarks TechEmpower Web Framework" est l'optimisation inégale .
Ces benchmarks n'utilisent pas les optimisations possibles (et par des développeurs expérimentés bien connus) sur ces frameworks ... du moins pour symfony2 et leurs tests c'est un fait.
Quelques exemples concernant la configuration de symfony2 utilisée dans leurs derniers tests:
- "composer install" n'est pas appelé avec l'indicateur -o pour vider un chargeur automatique de classmap optimisé ( code )
- Symfony2 n'utilisera pas le cache APC pour Doctrine annotations de métadonnées sans apc_cli = 1 ( issue )
- l'ensemble du conteneur DI est injecté dans le contrôleur au lieu des seuls services nécessaires
- par ceci l'injection de setter est utilisée -> crée un objet puis appelle la méthode setContainer () au lieu d'injecter le conteneur directement dans le constructeur (voir: BenchController étend Controller étend ContainerAware )
- un alias ($ this-> get ('service_name')) est utilisé pour récupérer les services du conteneur au lieu d'y accéder directement ($ this-> container-> get ('service_name')). ( code )
- ...
la liste continue ... mais je suppose que vous avez compris où cela mène. 90 questions ouvertes maintenant ... une histoire sans fin.
Développement & Ressources
Les ressources comme les serveurs et le stockage sont bon marché. Vraiment pas cher ... par rapport au temps de développement.
Je suis un pigiste facturant des tarifs très courants. vous pouvez soit obtenir 2-3 jours de mon temps ... ou une charge de ** ** de puissance de calcul et de stockage!
Lorsque vous choisissez un cadre, vous choisissez également une boîte à outils pour un développement rapide - une arme pour votre lutte contre le client qui ne se satisfait jamais complètement et qui vous fera payer bien pour ses souhaits.
En tant qu'agence (ou pigiste), vous souhaitez créer des applications riches en fonctionnalités en peu de temps. Vous serez confronté à des points où vous êtes coincé avec quelque chose ... peut-être un problème lié aux performances. Mais vous faites également face à des coûts et à du temps de développement.
Qu'est-ce qui sera plus cher? Un serveur supplémentaire ou un développeur supplémentaire?
Ce blog répond à la deuxième partie de votre question: http://symfony.com/blog/is-symfony-too-slow-for-real-world-usage
Rejeter symfony parce que la vitesse d'un test "bonjour le monde" n'est pas aussi bon qu'avec le framework FooBar est une erreur. La vitesse brute n'est pas le facteur clé pour les professionnels. Le coût est le facteur clé. Et le coût de développement, d'hébergement et de maintenance d'une application avec symfony est inférieur à ce qu'il est pour d'autres solutions.
Lors du choix d'un cadre, il faut tenir compte des coûts totaux de développement. Cela signifie examiner la qualité du code du framework (tests unitaires, documentation, etc.), les performances (et les coûts d'hébergement), la quantité et la qualité des fonctionnalités qu'il contient, la taille de la communauté, l'utilisation par les organisations comme le vôtre, l'évolutivité, etc.
En tant que développeur Symfony, je déteste passionnément WordPress d'un point de vue technique. Mais je vais quand même le recommander (et même l'utiliser!) Pour un site Web simple. Pas seulement parce que c'est de la popularité, mais parce que la taille de sa communauté: il est très facile d'embaucher un WordPress designer/développeur. En regardant une comparaison des performances entre WordPress et Symfony ne ferait aucun sens dans ce cas.