Le 19/07/10 20:54, Greg a écrit :
des cores dispos (moins de deadlock sur l'allocateur de PHP, qui est LE problème avec symfony)Intéressant, cette identification de bottleneck.
Merci xdebug.
En fait, quand on trace un site basé sur un framework un peu lourd, on constate souvent que le plus gros de la charge vient de l'initialisation de toute l'environnement du framework.
Sur des bases monolithiques comme symfony, c'est plusieurs milliers d'objets à créer pour servir une page simple.
L'allocateur de PHP n'est pas un modèle de perf ( environ O(n.log(n)) ), mais surtout il réaloue dynamiquement (merci le loose typing).
Quand on part sur un code assez sommaire en symfony, la vitese de chargement du framework est assez stable. Dès lors qu'une requette en base survient, c'est à tout l'ORM de se mettre en route. Pour peu que le debug soit actif, c'est plusieurs centaines d'objets à créer, avec un wait() à chaque allocation, le temps qu'elle soit acquitée.
Résultat, sur du code de prod (typiquement e-commerce avec scénario de parcours rapide), c'est 90% du temps passé sur PHP à gérer la mémoire.
Symfony n'est pas le seul dans ce cas, tous les frameworks monolithiques en souffrent, peu importe le langage. Mais c'est un peu moins prononcé sur des outils plus modernes (RoR ou Django).