XHTML.net
Technology talks by Loïc d’Anterroches
News, articles, PHP, scripts, XHTML/CSS, …
- Home
- PHP: Hypertext Preprocessor
Symfony 2 très lent, demande d'aide
The 2012-02-20 at 15:42 by Loïc d'Anterroches filed under PHP: Hypertext Preprocessor.
Je suis en train de faire des tests pour essayer de comprendre pourquoi Symfony 2 est particulièrement lent dans le test comparé de frameworks. Ils posent Symfony 2 à grosso modo 300 req/s, soit 10x plus lent que des frameworks Python comme Django. J’ai suivi la documentation, vérifié que j’ai APC, la cache, tout en mode production et je tombe sur 300 requêtes par seconde contre 2500 avec Photon (Mongrel2 compilé en mode debug). Sur le channel Mongrel2, d’autres testeurs qui utilisent Symfony normalement tombent sur la même conclusion. Apache sort 10000 req/s en statique sur la machine avec 5 connexions simultanées.
Le code de mon contrôleur Symfony :
<?php
namespace Foo\HelloBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Response;
class DefaultController extends Controller
{
public function indexAction($name)
{
return new Response('<html><body>Hello '.$name.'!</body></html>');
}
}
les routes :
FooHelloBundle:
resource: "@FooHelloBundle/Resources/config/routing.yml"
prefix: /
hello:
pattern: /hello/{name}
defaults: { _controller: FooHelloBundle:Default:index }
J’ai créé le code avec l’application en ligne de commande comme dit dans la doc. La configuration est la config config.yml de base sans profiler, sans debug. J’ai pas envie de faire de l’injection de dépendance à un consultant Sensio à XXX€ de la prestation pour un test de Symfony sur un hello world, donc je demande de l’aide au peuple. Est-il possible de sortir un peu plus de Symfony? 300 req/s sur une machine de qualité, cela veut dire qu’il me faut plus qu’un serveur pour supporter la une de Hacker News ou Reddit, ce n’est pas normal. Je cherche donc un config.yml le plus simple et optimisé. Merci de votre aide.
Mise à jour pour les trolls :
Je remets mon commentaire de plus bas ici. Le test comparé de frameworks donne :
- Django : 2159 req/s
- Symfony2 : 273 req/s
Si vous me dites que vous avez besoin de Varnish pour faire tenir un site PHP alors vous avez perdu et j’ai honte. Le test comparé fait la une de HN pendant une journée complète. Ce que vous dites c’est que vous avez renoncé à faire du PHP conventionnel qui va vite et bien avec un framework qui vous aide dans le développement. Cela veut dire que les gens qui voient ces tests et ont le choix vont chercher ailleurs et ne vont pas toucher PHP. Cela veut dire que toute la communauté PHP va perdre. Cela n’a rien à voir avec Symfony2 vs. Photon, Photon est un projet qui restera toujours petit car ne suivant pas le concept de PHP de base.
Sub Categories
- Photon
- Pluf - Framework en PHP5
Mon entreprise
- Céondo Ltd
- Cheméo
- Baregit Git Hosting
- InDefero, bug tracker++
Logiciel libre
- Plume CMS
- Pluf - PHP5 Framework
- Planète PHP.fr
Sur ce site
- Logiciel libre et entreprise
- PHP Naive Bayesian Filter
- Search and search/replace strings in files
Website feed
Category feed
Comments from readers
Julien DIDIER said:
Salut,
Faire un test de montée en charge avec un HelloWorld sur Symfony2, c'est certain que c'est pas optimal. Symfony2 n'est pas fait pour afficher "hello world" le plus rapidement possible.
Pour les problématiques de perf, il y a certe une optimisation du code et des dépendances (swiftmailer, doctrine, ...), mais il y a aussi les systèmes de cache (Varnish ?).
Marc said:
* disclaimer : Je travaille chez Sensio.
Outre l'aspect trollesque du post (sources, possibilité de refaire les tests et tu es le dev de photon), si tu veux tenir cette charge, tu mets un varnish devant ton application et tu mets les headers de cache correspondants dans ta Response sf2. Ca sera bien plus efficace et cohérent, dans ce cas d'utilisation.
Ludo said:
Juste une question, vu ton analyse et ton besoin, pourquoi tu ne fais pas une bête page html ?
Je ne suis pas un expert du bench, mais le bon outil pour le bon besoin c'est le B-A-BA.
Alexandre Salomé said:
Hello,
Un premier moyen d'augmenter la performance serait déjà de désactiver toutes les fonctionnalités inutiles pour un hello world : sessions, forms, translations, etc.
Dans config_prod.yml, les optimisations de Doctrine sont désactivées, également.
L'autoloading pourrait être allégé, car il prépare Swiftmailer, and so on.
Alexandre Salomé said:
Ou sinon :
class myKernel extends HttpKernelInterface {
public function handle(...)
{
return new Response('Hello world');
}
}
et ça reste du Symfony ;-)
Tim said:
J'ai ça en bookmark si ca peut aider:
https://github.com/symfony/symfony-hello-world
naholyr said:
Un peu gros comme troll, passera pas :)
On n'est pas simplement en train de parler d'une différence fondamentale entre stateful qui maintient une application vivante qui traite les requêtes à la volée (à la java, node, python, ou même photon puisque tu sembles y tenir ;)) et stateless qui doit pour chaque requête ouvrir un contexte puis le refermer (php, cgi, etc.) ?
Didier said:
Personnellement, ma boîte a du opérer en catastrophe à la migration d'une application métier développée en Symfony2 sur une autre plateforme (évitons ici le troll et passons la sous silence), suite à un afflux non-planifié de trafic… toutes nos investigations ont rapidement montré de réels problèmes de tenue à la charge, notamment à mesure que les accès concurrents se multipliaient, et ce dans des proportions déraisonnables en regard de ce que permet de faire les plateformes concurrentes.
Les retours des personnes en charge du développement et de la maintenance étaient :
- performances désastreuses dès que la charge augmente, elles s'écroulent de façon logarithmique avec la multiplication des accès concurrent
- difficulté de paramétrer efficacement les caches HTTP partiels
- difficulté d'auditer les goulots d'étranglement du fait des très nombreuses strates programmatiques, vraisemblablement à l'origine d'un affaissement des performances
Il serait intéressant d'avoir une analyse plus détaillée des causes profondes de ces problèmes de performances, et que des actions soient prises pour éviter ce type de mésaventure, car sinon en dehors de ça l'API et les fonctionnalités sont d'excellente facture !
Alexandre Salomé said:
Aussi dans la configuration, désactives le session auto start.
Exemple : https://github.com/alexandresalome/the-great-web-framework-shootout/commit/9226a6aa69f7404d7f01703f0487699a9f38609e
Marc said:
* Disclaimer Je travaille chez Sensio Labs
Pour info, youporn.com (oui oui, j'ai bien écrit ça) vient d'être migré vers Symfony2. Ils en sont très content apparemment.
Source:
groups.google.com/group/symfony-devs/browse_thread/thread/586328a113e39846/85caf9db8a280f77?q=symfony+manwin#85caf9db8a280f77
Julien DIDIER said:
De toute façon le PHP c'est has been !
Vive les sites statiques en HTML et Javascript \o/
Loïc said:
Hello, ce n'est pas un troll ! Quand vous avez un shootout qui donne :
https://github.com/seedifferently/the-great-web-framework-shootout
Django : 2159 req/s
Symfony 2 : 273 req/s
Je suis désolé mais cela fait honte à PHP. Annoncer ensuite que si vous voulez un site qui sorte des requêtes il faut avoir Varnish devant est ridicule alors que tous les gens en Python/Ruby/Scala/Erlang n'ont pas besoin de cela, vous pensez quoi ? Aujourd'hui, quand vous avez un lien comme le shootout qui tourne en première page de HN pendant 24h, comment voulez-vous qu'ensuite les gens disent "PHP c'est bien" ? Ce que je veux pouvoir dire en sortie c'est "Non, Symfony2 c'est aussi rapide que Sinatra quand c'est bien configuré." C'est ça que je veux.
Alexandre Salomé, merci, c'est ce que je cherche comme info !
tsorrow said:
Et avec ZF2 :) ?
Loïc said:
tsorrow, je n'ai strictement aucune expérience avec et Symfony est le plus facile à installer.
Alexandre Salomé said:
And as stof said on this page : https://github.com/alexandresalome/the-great-web-framework-shootout/commit/9226a6aa69f7404d7f01703f0487699a9f38609e
You should also disable some bundles in AppKernel.
Once upon a commit, Fabien Potencier created such a test sandbox : https://github.com/fabpot/framework-benchs
Maybe you should first integrate mentioned optimizations in your job and give us update about it.
Loïc said:
Alexandre, yes, this is also why I went on the #symfony channel on freenode to ask for help (stof was nice to answer). Really, this annoys me as much as you to have PHP put under such bad light against the other language frameworks (Python/RoR/etc.).
Lionel said:
CodeIgniter (MVC classique, inspiré de RoR) fait beaucoup mieux que Symfony2, donc hors alternatives moins classiques comme Photon ou autres, c'est clair qu'il y a un truc qui cloche dans la stack Symfony ; à moins qu'une meilleure configuration ne permette une amélioration massive.
Et il reste à savoir où ça cloche...
Loïc said:
Lionel, effectivement. En fait, selon Stof sur le channel #symfony de freenode, pour avoir un hello world optimisé avec Symfony, il faut non seulement avoir une config optimisé, du code optimisé mais il faut aussi aller coder dans le "Kernel" de Symfony. Cela nécessite donc beaucoup de travail que je ne peux même pas faire car il faut très bien connaître Symfony 2 pour le faire :-(
Alexandre Salomé said:
Un autre framework intéressant qui pourrait être ajouté est Silex. Il est basé sur Symfony, mais ça n'est pas le framework full-stack (symfony-standard edition).
Loïc said:
Vraiment merci Alexandre pour toutes tes remarques. Il faudrait un hello world optimisé directement dans l'archive Symfony 2, cela aiderait aussi les développeurs à affiner leur application.
Fred said:
Si symfony est aussi lent par défaut, c'est peut-être que malgré sa conception modulaire et ses multiples couches d'abstractions, il soit tout simplement devenu une usine à gaz à l'image de ce qui se fait en java.
Peut-être que PHP sert finalement à faire des choses simples...
Mais bon c'est pas grave les marketeux arriveront quand même à le refourguer à nos bonnes vieilles SSII :)
Laurentj said:
Les réponses des spécialistes symfony me sidèrent, et montrent au final à mon avis des gros problèmes dans sf2. Par exemple :
>L'autoloading pourrait être allégé, car il prépare Swiftmailer,
gni ?? l'autoloading prépare swiftmailer ? Que vient faire swiftmailer dans le processus de bootstrap ?? Sur un site web, l'envoi de mail est assez anecdotique quand même. ça doit concerner 1 requête http sur 1000, ou 10000, voir plus. Bref, cela veut dire donc que la plupart du temps, swiftmailer est "préparé".. pour rien. Du grand n'importe quoi.
Si tout le reste est comme cela, ce n'est pas étonnant que SF2 soit si lent.
@naholyr oui, c'est vrai on compare des architectures différentes stateless/statefull. Mais justement, je pense que dans SF2, ils ont oublié que PHP, ce n'est pas du java, et donc que des design pattern valables pour Java et autres technos stateful, comme l'injection de dépendances etc, ne sont pas forcément la meilleur chose à mettre en place dans des technos stateless comme PHP, ou en tout cas, à utiliser avec modération (ce qui n'est pas le cas dans SF2)... Parce que ce sont des trucs très gourmand en ressources, mêmes avec des optimisations dans tout les sens.
Pour bien faire, faudrait que ce soit des fonctionnalités natives du langage...
Seza said:
La réponse de Marc est assez hallucinante, j'espérais ne pas avoir à entendre ce genre de discours dans la communauté PHP qui consiste à dire si tu veux faire le job, met une facade devant notre produit car nous on encaisse pas.
Je serais curieux d'avoir les résultats de :
- Silex comme la mentionné Alexandre.
- Fuel PHP qui à le vent en poupe c'est derniers temps
- Lithium avec une piste pour faire un benchmark dev.lithify.me/lithium/wiki/blog/thanksgiving-benchmarks
rebolon said:
Effectivly you should disable all unneeded bundle in your appKernel.php : Security, Twig, Monolog, SwiftMailer, ...
Then modify your config.yml to remove all related rows to the removed bundles : swiftmailer ...
Then clear the cache using this command : php console cache:clear
Then generate assetic with php console assetic:dump (only if you use assetic in template)
But if you test Twig, you have to know that this template engine is rather slow. So you should try to test without it.
Give us the new result.
And you should also try Silex.
foxmask said:
Bonjour,
Quelqu'un s'est chargé de silex https://github.com/seedifferently/the-great-web-framework-shootout/pull/15 avec le resultat dans le pull
et fuelphp https://github.com/seedifferently/the-great-web-framework-shootout/pull/18 mais sans resultat.
rebolon said:
Have a look to this slideshow : slides.seld.be/?file=2011-10-20+High+Performance+Websites+with+Symfony2.html#1
I really like the routing optimization : use this app/console --env=prod router:dump
And copy/paste the result in your .htaccess
You will then bypass symfony2 routing and use only apache
But there is also some other optimization (autoload maybe, doctrine cache...)
Bertrand Mansion said:
A mon avis, Symfony 2, comme Zend Framework, sont lents pour les raisons suivantes :
1. Pour que le framework soit largement adopté, il faut qu'il propose beaucoup de fonctionnalités, ou du moins qu'il en ait l'air. Or cela nécessite de prendre en compte un grand nombre de demandes des utilisateurs, certaines parfois saugrenues, comme par exemple l'intégration de SwiftMailer dans Symfony 2 ou Gdata dans Zend Framework. Les utilisateurs de ces frameworks cherchent avant tout à gagner du temps en développement et se reposent donc sur ces fonctionnalités proposées par le framework. Toutes ces fonctionnalités alourdissent l'ensemble.
2. Il y a aussi une volonté commerciale de la part des entreprises derrière ces projets. En développant un framework lent, nécessitant certaines compétences en tuning, ces entreprises peuvent vendre des services. Dans le cas de Zend, c'est flagrant puisqu'elle commercialise une solution serveur optimisée avec un système de cache maison. Dans le cas de Symfony, en lisant le deuxième commentaire de la personne qui travaille chez Sensio, on constate qu'il est conseillé d'installer Varnish pour obtenir des performances correctes or ceci dépasse souvent le niveau de compétence d'un utilisateur de framework qui a initialement adopté le framework pour ne pas se prendre la tête avec certains aspects plus complexes du développement web.
3. Ces frameworks sont très éloignés de la nature dynamique et procédurale de PHP. En général, ils ne proposent que des solutions objets avec un nombre parfois effrayant de classes et de fichiers pour résoudre une tache simple. Rasmus Lerdorf est le premier à dire que ces gros frameworks alourdissent généralement le développement en PHP et ne tiennent pas compte des spécificités du développement en PHP en ignorant une bonne partie des fonctionnalités proposées par le langage. Ces frameworks seraient certainement plus performants en Java.
Ca n'engage que moi, mais je pense qu'un bon développement en PHP se fait avec un micro framework, ou si on connait bien le langage, avec son propre framework. Je considère ces frameworks comme des aberrations créés par des "frustrés" de Java. Aujourd'hui, les langages qui marchent sont loin de tout ça, Javascript et CoffeeScript, Lua, Ruby, des langages souples et dynamiques qui permettent plus de souplesse. Les frameworks PHP intéressants sont justement ceux qui savent rester légers et rapides, ce qui est beaucoup plus difficile à réaliser finalement que ces gros frameworks car cela demande de la créativité et de l'élégance.
Ce qui est génial avec PHP, c'est qu'on peut coder dans de nombreux styles (surtout avec PHP 5.4), en fonction de son besoin. C'est sûr qu'il est plus rassurant d'utiliser un gros framework, mais c'est tellement ennuyeux et cela se termine souvent par des problèmes de performance ou de maintenance. De nos jours, il faut savoir être "agile".
laurentj said:
@bertrand : +100. Voilà des propos lucides et tellement vrai. Entièrement d'accord avec toi
foxmask said:
Bonjour,
L'espace d'un instant j'ai cru lire des propos de Laurentj derrière ceux de Bertrand. Le Leitmotiv de Laurentj avec Jelix étant clairement proche du "Keep It Simple and Smart" (KISS).
Tout cela touche "ma" corde sensible du dev qui veut du robuste efficace et _léger_.
Si enfin un bon gros rayon de Soleil pouvait s'arrêter sur ces projets "petits mais costauds" (cités ici xhtml.net/php/697-Vitesse-de-Symfony-2-reponse-aux-commentaires), alors peut-être que la vision de beaucoup de monde changerait vis à vis de PHP.
Autant ces projets regardent comment les "gros" font telles ou telles choses mais il ne serait pas idiot qu'ils en fassent autant et revoient leur copie sur ce qui cloche. Juste histoire de redorer le blason de PHP.
Vince said:
Bonjour,
Je suis à la base un grand fan de Symfony (pour avoir développé quelques "gros" projets en Symfony 1.x).
Je suis déçu d'apprendre de telles performances pour sf2 que je comptais utiliser pour la v 2.0 de notre gros backend qu'on recommence from scratch (plus de 3 ans qu'on le développe). Je remettrai sans doute en question mon choix du framework (et du langage) en temps voulu (j'ai déjà commencé).
Je ne suis cependant pas totalement d'accord avec ce qui s'est dit plus haut :
Bertrand Mansion:
"1. Pour que le framework soit largement adopté, il faut qu'il propose beaucoup de fonctionnalités, ou du moins qu'il en ait l'air. Or cela nécessite de prendre en compte un grand nombre de demandes des utilisateurs, certaines parfois saugrenues, comme par exemple l'intégration de SwiftMailer dans Symfony 2 ou Gdata dans Zend Framework. Les utilisateurs de ces frameworks cherchent avant tout à gagner du temps en développement et se reposent donc sur ces fonctionnalités proposées par le framework. Toutes ces fonctionnalités alourdissent l'ensemble."
Le framework peut proposer ces solutions sans pour autant les activer et les charger par défaut, Cela n'empêchera pas les développeurs d'opter pour lui. Oui les développeurs veulent du rapide, mais lancer une quelconque commande (ou rajouter une ligne de code) pour charger les composants voulus ne demande pas beaucoup plus de temps (sur l'ensemble du projet).
On est bien d'accord que tout charger via l'autoload n'est pas la bonne solution (que sf2 semble faire par défaut).
"2. Il y a aussi une volonté commerciale de la part des entreprises derrière ces projets. [...]"
Dans le cas d'un projet opensource tel que Symfony où il y nombre d'apports venant de développeurs, je ne suis pas convaincu que cela a été fait intentionnellement pour des raisons financières. Mais dans ce cas, cela devrait être relativement "vite" corrigé, ne fut-ce que par les développeurs. Mais ceci reste mon avis.
Ma conclusion actuelle est donc :
- Quoi qu'on en dise, Symfony est déjà une belle avancée par rapport à du php brut (dans notre jargon du "cras php").
- Symfony 2 semble avoir, selon les benchmarks proposés, effectivement des sérieux problèmes de performances. Mais cela peut encore changer, la v2 est toute jeune.
- Il ne suffit pas uniquement de taper sur tel ou tel framework mais proposer aussi des solutions.
Faire en sorte que l'autoload ne chargent pas les classes rarement utilisées (comme swiftmailer dans les commentaire) en est une bonne. Mais il ne faut pas s'arrêter là.
- Je pense que Symfony2 peut réellement être un framework puissant et performant à la fois (moyenne un certain travail). Il faudra cependant garder en tête qu'il n'est pas adapté à tout type de projet. A un problème correspond des outils adaptés et d'autres moins adaptés. Il faut rester logique, on utilise pas un framework (même un micro framework) pour faire un "hello world" ! C'est aussi facile voir plus simple de le faire sans framework, pourquoi le faire avec ? Si on continue la logique, c'est aussi absurde de mesurer un framework sur un 'hello world' puisqu'il est n'est pas l'outil adapté pour ça...
Vincent
Nico said:
@Vince : un hello world ne mesure pas un framework "mais" donne une bonne indication, surtout si un simple hello world montre déjà de grosse faiblesse.
Je trouve que SF2 c'est beaucoup de marketing mais hélas pas une solution pour développer.
Un bon framework doit être simple, améliorer la productivité, avoir une organisation de code (final) maintenable, sécurisé et être léger, très léger.
On est hélas trés loin de tout ça avec SF2. C'est long, ça rame et c'est flou.
J'ai l'impression qu'en codant avec SF2 on essaye de renier un maximum le PHP en passant à outrance par des fichiers de config.
Je préfère de loin faire une configuration "directe" en PHP que passer par des yml et xml.
rebolon said:
@Nico
Je ne pense pas que Symfony2 renie les principes de PHP. Effectivement il semble lourd (mais en modifiant le config.yml on double les perfs facilement), mais je trouve qu'il permet de simplifier l'industrialisation du développement. Je ne dis pas que les autres ne le font pas, mais l'architecture de Sf2 me plait. Elle est finalement proche de Copix (faudrait que je regarde Jelix un jour) mais il est vrai que la performance ne semble pas être au rendez-vous de manière native. Si j'arrive à avoir 5000 requêtes sans framework, j'aimerai bien obtenir au moins 1000 requêtes avec un framework (et c'est un minimum). Las, ce n'est pas le cas, loin s'en faut. Mais alors vers quel framework faudrait il se tourner ?