Discussion :

[vgross]

Bonjour à tous !

Je viens de développer un très gros projet sur Symfony 2. Dans ce projet, j'utilise (avec Doctrine 2) beaucoup de relations OneToOne, ManyToone, ManyToMany uni ou bidirectionnelle car super pratique ensuite de récupérer les variables dans la partie Vue (Twig).

Pour trier mes listes d'objets (par exemple trier mes objets "actualités" par date, ces "actualités" sont apparenté aux actualités facebook), je fais aussi souvent appel à un itérateur sur mes ArrayCollection dans mes contrôleurs comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
foreach($user->getInfos()->getFollowings() as $fol)
    		{
    			foreach($fol->getActus() as $a)
    			{
    				$actus[] = $a;
    			}
    		}
    		$iter = $actus->getIterator();
    		$iter->uasort(function($a, $b) {
    			$name_a = (int)$a->getDate()->getTimestamp();
    			$name_b = (int)$b->getDate()->getTimestamp();
 
    			return $name_a == $name_b ? 0 : $name_a < $name_b ? 1 : - 1;
    		});

Bref, tout ça marche à merveille et c'est vraiment magique pour de gros projets complexes comme le mien, cependant je me pose une question (peut être un peu tard vu qu'on est en phase de test), c'est au niveau performance !

Dans un objet "Commentaire par exemple" j'ai une relation ManyToOne avec un User (normal, un utilisateur fait un ou plusieurs commentaires...) et donc dans Twig avec la magie de ces relations j'ai accés à la variable "user" comme ceci {{ comment.user }} mais à travers cette variable, j'ai accès à toutes les informations de l'user en question (tous les commentaires, les articles, etc. qu'il possède)

Pour l'instant le site marche très bien sachant que nous sommes 2 utilisateurs. Mais lorsque que ce site sera ouvert au public va-t-il demander un serveur ultra performant ? pour le moment j'administre un VPS chez OVH (la plus petite formule) mais j'ai vraiment peur qu'il ne tienne pas la charge ?

Qqn a-t-il déjà fait un gros projet sur Symfony / Doctrine 2 ? En appelant les consultants de Sensio labs, j'ai cru comprendre que sur de gros projet, l'ORM était débranché :-/ donc ça veut dire que je devrais absolument tout redévelopper ?

Si qqn s'y connait un peu mieux ou peut m'éclairer sur un moyen de tester tout ce bazard avant la mise en ligne ça serait génial !

Merci à tous

PS: je sortirai bientôt mon blog, j'y mettrais dedans toute mes découvertes autour de Symfony 2 (y'en a eu énormément depuis le début de mon projet) et j'ai fait pas mal de bout de code qui pourront servir à d'autres projets !

[rawsrc]

En appelant les consultants de Sensio labs, j'ai cru comprendre que sur de gros projet, l'ORM était débranché :-/ donc ça veut dire que je devrais absolument tout redévelopper ?

Bah écoutes, partout où je suis passé sur des gros projets PHP, l'ORM avait toujours été interdit et la seule fois où je suis tombé sur Doctrine, il était question de le virer. Personnellement, je ne comprends pas du tout cet engouement autour des ORM. Le SQL offre déjà tout ce qu'il faut pour faire ce dont on a besoin et même plus encore. Je pense qu'il est préférable (et de loin) de bien maitriser le SQL avec un moteur de SGBD que de masteriser dans un ORM.

Ensuite l'argument marketing qui te dit qu'avec l'ORM tu peux faire abstraction de la base de donnée, c'est du grand n'importe quoi. Je n'ai jamais entendu dire dans une entreprise qu'on changeait de moteur de base de données comme de chemise...

Côté performances, il n'y a pas photo : une requête SQL bien écrite ou une procédure stockée bien montée sera toujours plus performante que n'importe quel outil ORM. Sans compter que le SQL est normé, d'où une "certaine" portabilité d'un moteur à l'autre alors que l'ORM fait sa salade dans son coin et il faut généralement en plus se palucher un langage de requêtage spécifique (DQL pour Doctrine).

Bref, une perte de temps pure et simple à mes yeux accompagnée d'une sacré dégradation des performances.

Rencontrer un développeur qui n'est pas compétent en SQL c'est comment dire, assez rare de nos jours.

Pour ton problème spécifique, en plus du cache APC (symfony2), tu devrais utiliser un sacré cache HTTP, histoire de court-circuiter au maximum l'ORM. Vu que ce n'est pas encore en production, c'est le bon moment d'estimer le temps qu'il te faudrait pour sortir Doctrine de ton projet.

[vgross]

Voila typiquement le genre de réponse que je craignais...

Sortir l'ORM d'un projet Symfony 2 avec tout le dev que j'ai déjà fait, ça va me prendre pas mal de temps vu que je suis seul au dev... mais malheureusement je vais devoir me pencher sur cette solution si les performances en prod sont médiocre et au vu de ce que tu me dis...

C'est vrai que le délire de changer de base sur un projet PHP c'est pas très courant mais si j'ai utilisé Doctrine, c'est uniquement parce que j'ai voulu développer mon projet avec Symfony 2 et qu'en natif, c'est cet ORM qu'ils ont choisis...

Bon et puis il faut pas non plus oublier le coté ultra pratique d'un ORM. J'ai appris l'SQL à l'école et vu tout le dev et le peu de temps que j'avais pour le faire, j'étais content de pas revoir tous mes cours car dans ce projet j'ai énormément de relation entre mes entités...

Bref, si qqn à un autre avis sur ce débat (même si c'est le même que rawsrc), qu'il n'hésite pas !

[dourouc05]

Bref, si qqn à un autre avis sur ce débat (même si c'est le même que rawsrc), qu'il n'hésite pas !

Des caches, des caches et encore des caches. Doctrine2 en propose en natif : http://docs.doctrine-project.org/pro...e/caching.html.

Les ORM, je les adore pour simplifier le développement, je trouve ça nettement mieux pour ne pas devoir penser en termes de SQL et autres (mon cerveau est orienté objet, ça explique). Ensuite, Doctrine 2 est suffisamment bien pensé pour qu'on puisse s'en débarrasser (toutes tes classes qui constituent ton modèle... rien ne les lie à Doctrine ! il suffit de refaire toi-même dedans tout ce que Doctrine fait lui-même). Tu peux aussi migrer seulement ce qui pose problème (ApacheBench pour un petit stress test, voir les pages qui sont trop lentes, bypasser l'ORM pour celles-là en priorité). De mon côté, je ne me passe pas d'ORM, mais avec un cache (quitte à rendre certaines pages entièrement statiques et ne les régénérer que quand les données changent, mais ça varie d'un projet à l'autre).

[Tsilefy]

Pour apporter un point de vue, je ne pense pas que les (nombreux) utilisateurs d'Hibernate, d'Active Record ou de Django s'en serviraient si l'utilisation d'un ORM n'était pas plus efficient (dans tous les sens, et pas uniquement au niveau de la performance pure) qu'une requête directe.
De plus, pour vraiment faire une différence qui soit flagrante, je pense qu'être développeur Web avec des bonnes connaissances en SQL ne suffit pas, il faut également être spécialisé en SQL et tout optimiser de la conception de la base à son utilisation, ce qui ce justifie dans des très gros projets d'entreprise avec une équipe, et non sur un "gros" projet développé individuellement, ce qui semble être le cas de l'OP.
Pour moi aussi, l'avantage principal de l'ORM, c'est de ne plus penser en SQL. Quand je conduis une voiture, je sais que le moteur tourne, et ça me suffit. Je n'ai pas besoin de savoir son implémentation.
Et si on veut aller dans la performance et que le problème soit SQL, autant passer directement à Reddis :
http://twitter.com/#!/AntonShevchuk/...09870573568000 (un peu NSFW).
Je sais qu'il existe un bundle, mais je n'ai pas testé.

[rawsrc]

Il faut comparer ce qui est comparable. PHP étant par définition stateless, un ORM est une ineptie. Les autres environnements techniques de certains autres langages bénéficient généralement de serveurs d'applications qui rendent ces solutions utilisables. Ce n'est pas le cas de PHP.

Pour Redis ça n'a rien à voir avec une base relationnelle classique du style MySql. Ce n'est pas comparable. D'un côté on est dans une solution basée sur du clé-valeur (Redis) et de l'autre on est sur du relationnel.

Quant à l'argument : je ne pense plus SQL... J'utilise moi-même la programmation orientée objet partout mais je ne rechigne pas à pondre des procédures stockées ou des requêtes chiadées en cas de nécessité. Sans compter que comme le souligne Tsilefy, l'optimisation démarre dès le début du projet et pas en cours de route, ce qui se traduit généralement par un design soigné de la base. Donc ne plus penser SQL sous prétexte de penser objet n'est pas du tout obligatoire ni même conseillé je pense.

Après chacun fait en gros un peu comme il veut, mais utiliser partout des caches en pagaille sous prétexte que des outils tiers dégradent sensiblement les performances relève à mes yeux de la rustine. Ce qui est valable pour d'autres environnements ne l'est pas pour PHP. A ce rythme, je ne pense pas que cela soit dans l'intérêt du PHP de devenir un java like. Autant aller directement à la source.

[Guybrush113]

Sujet très intéressant !

Je pense qu'il faudrait aussi définir qu'est-ce qu'une "grosse utilisation" ou un "gros projet", et à partir de combien de "temps" on considère qu'une page est moins performante.
Je parle surtout pour l'OP, avant de se mettre tout de suite à tout changer, bien réfléchir si ca vaut le coup.

[vgross]

Non mais avant de tout recommencer, je vais dans un premier temps optimiser toutes mes requêtes avec les jointures qui vont bien car j'avais omis cette partie indispensable (je suis sur ça en ce moment et je bloque sur une jointure mais je vais le poster dans un autre message car ce n'est pas du tout le sujet du débat).
Ensuite je me débrouillerai pour utiliser le cache APC de doctrine afin de stoker dans le cache les requêtes générées et les objets mais je n'en suis pas la et je sais même pas encore comment ça marche et si c'est possible ?

A la suite de ça je verrai si la perte le performance et trop énorme et si c'est le cas, je me débarrasserai de Doctrine au fur et à mesure...

Que pensez vous de cette direction ?

[RapotOR]

J'ai une application de 92 entités qui fonctionne relativement bien sur Symfony2/Doctrine2 (windows server 2003).
Avec les différents cache (apc) et éventuellement des caches bêtes et méchants de vues entières pour les requêtes vraiment gourmandes, l'application fonctionne plutôt bien.

J'ai essayé
- de faire les requêtes les plus précises possibles pour ainsi éviter le chargement d'entités pas utilisées;
- mais également; à l'inverse; éviter le chargement LAZY alors qu'il ne doit pas l'être dans le cas où l'entité sera au final tout de même chargée.

Je souhaite aussi attirer l'attention sur les formulaires. C'est souvent magique mais cela peut vite devenir gourmand! Certains types ont l'art de faire des requêtes pour nada! Je pense particulièrement à EntityType ou imbrication de formulaire en Collection.

Règle d'or: Il est vraiment obligatoire d'observer les requêtes effectuées par l'ORM à chaque action. Les surprises sont courantes et sont simples à corriger dans la plupart des cas!

[vgross]

Aurais-tu un exemple d'utilisation du cache APC avec doctrine 2 pour les requêtes ou les objets sur un GitHub ou un Blog ? ça m'arrangerait énormément car la doc Doctrine 2 n'est pas très poussée :-/

[stealth35]

Aurais-tu un exemple d'utilisation du cache APC avec doctrine 2 pour les requêtes ou les objets sur un GitHub ou un Blog ? ça m'arrangerait énormément car la doc Doctrine 2 n'est pas très poussée :-/

http://symfony.com/doc/2.0/reference...aching-drivers

[WebDream]

Il faut comparer ce qui est comparable. PHP étant par définition stateless

Quelqu'un pourrait m'expliquer la réelle différence entre un langage stateless et stateful ?

D'après ce que je comprends PHP peut aussi conserver des états avec les sessions non ?

Quels sont des exemples de langages web stateful ?

Python et Ruby sont-ils stateful ou stateless ?

Merci.

[rawsrc]

Quelqu'un pourrait m'expliquer la réelle différence entre un langage stateless et stateful ?Merci.

Un langage n'est pas stateful ou stateless, c'est un raccourci linguistique. Ce qualificatif est propre en l'ocurrence au fonctionnement de la technologie sous-jacente à un langage dans un environnement technique donné (serveur web en l'ocurrence).

Stateless et statefull correspondent à la possibilité de gérer ou pas des états conversationnels entre les appels.
Je m'explique, cela veut dire que le serveur peut garder des éléments en mémoire (vive) entre les appels et quand un client re-soumet une requête, un état de conversation privé entre le serveur et le client est déjà présent en mémoire.
Pour palier ce manque, PHP utilise des session qui gardent cet état conversationnel en dur dans un fichier ou une base de donnée. Mais entre chaque appel, la mémoire est purgée et il est nécessaire au serveur de recharger la totalité des données de session et de reparser tous les scripts nécessaire à une réponse. C'est pour cela que l'on dit que PHP est stateless. L'avantage principal de ce choix technologique c'est que vu qu'il n'y a pas de liens pérennes entre les appels successifs, il est tout à fait possible de dérouter le traitement d'un requête sur un autre serveur PHP te permettant ainsi d'absorber plus facilement des pics de traitements.

Dans un système statefull, tout reste en mémoire et généralement, il est plus difficile de dérouter un traitement vers un autre serveur. Le gros plus c'est que tu ne charges que les éléments nouveaux, d'où un temps de traitement sacrément plus court.

Pour en revenir à PHP, il serait tout à fait possible d'utiliser un ORM à condition que le moteur PHP n'ait pas à recharger à chaque appel la structure de la base qui elle est généralement immuable. En gros, il serait bien d'avoir l'équivalent d'un petit serveur d'applications pour PHP qui garderait en mémoire tout les éléments redondants (ORM, Framework...). Au final, plus de traitements redondants, juste la partie nécéssaire à la requête. Bref du travail optimisé.

C'est la raison pour laquelle, tous ces outils (ORM, Framework) nécessitent encore des outils de cache qui te permettent de soulager le parser PHP vu que généralement tu le court-circuites.

Donc mon opinion est que c'est outils rendent bien évidemment des services mais vu la configuration technique de PHP, ils sont inadéquates. C'est tout. Bon, j'admets qu'il est difficile de se passer d'un framework mais d'un ORM si.

[devlamine]

comparaison de framework web compris symfony 2:
https://github.com/seedifferently/th...ework-shootout

[vgross]

Wow ! C'est quoi ces scores pour Symfony 2 ? je dois m'affoler la ou c'est normal ???

[stealth35]

Wow ! C'est quoi ces scores pour Symfony 2 ? je dois m'affoler la ou c'est normal ???

c'est normale, c'est un test naze type "Hello World"

https://github.com/alexandresalome/B...For-Benchmarks

[devlamine]

voila un comparaison avec la BDD:
http://blog.curiasolutions.com/the-g...work-shootout/

[stealth35]

voila un comparaison avec la BDD:
http://blog.curiasolutions.com/the-g...work-shootout/

C'est toujours pareil, tu ne peux pas comparer des choses sur qu'une seule valeur, mais plutôt sur une application entière.

C'est comme si tu comparais des voitures en chronométrant celle qui démarre la plus vite, ça n'a pas de sens.
Pour comparer des voitures on test plein de choses suivant ses besoins :

Une voiture qui pète le 0-100 en 3s
Une voiture qui fait 1500km avec un plein
Une voiture avec 8 place
...

On compare ce qui est comparable

[dourouc05]

Wow ! C'est quoi ces scores pour Symfony 2 ? je dois m'affoler la ou c'est normal ???

Simplement lire tout l'article :

Do these results have any real world value?

Probably not. When it comes to code, the slightest adjustments have the potential to change things drastically. While I have tried to perform each test as fairly and accurately as possible, it would be foolish to consider these results as scientific in any way. It should also be noted that my goal here was not necessarily to figure out how fast each framework could perform at its most optimized configuration (although built-in caching and other performance tweaks were usually enabled if the default configuration permitted it), but rather to see what a minimal “out-of-the-box” experience would look like.

Additionally, nothing here is intended to make one web technology appear “better” than another. When it comes to using the right tool for the job, “faster” does not necessarily mean “better” (very few real world projects are going to depend solely on page request speeds).

En d'autres termes : +1 pour stealth, tant qu'on ne me montre pas un comparatif pour des applications (pas une page, vraiment quelques-unes : un petit site à tout le moins, avec livre d'or, partie blog, etc., en comparant plusieurs modes de fonctionnement - avec ou sans cache fichier/APC, avec ou sans ORM, avec ou sans moteur de templating, etc.).

[spike2]

Pour mon expérience de SF2, j'ai travaillé sur un gros projet avec des milliers d'utilisateurs actuellement.

Une dizaine de bundle avec son lot d'entité à l'intérieur, utilisation d'ORM donc. Personnellement nous sommes très satisfait du résultat une fois le site passé en prod, le système de cache de sf2 se révèle tout à fait performant.

De plus on s'est aperçu il n'y a pas longtemps qu'on avait omit d'activer le cacher de doctrine2, c'est à dire mettre en cache toutes les annotations entre autre pour ne pas à avoir à repasser dedans à chaque fois, pourtant le site tournait bien.

(Si vous regardez dans config_prod.yml, il y a une partie en commentaire de base, à dé-commenter donc, si votre serveur n'a pas de problèmes avec bien sûr)

Le nombre de requêtes sql est cependant important, mais il s'avère que l'utilisation de Gedmo translatableBundle en soit une des causes principales, je vous le déconseille. Après comme quelqu'un l'a dit, si vous faites les bonnes jointures et des requêtes optimisées il n'y a pas de problèmes.

Nous avons déjà plusieurs gros sites qui tournent sur SF2 et nos retours d'expériences sont satisfaisants...Il y aura toujours des gens pour et des gens contre après

Bon dev !