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.