Forum d'entraide PHPFrance

Voilà je dev actuellement sur symfony dans le cadre de mon travail ce qui permet me permet de mieux maitriser cet outil.
Mais voilà je me pose pas mal de questions desssus et principalement sur ces performances d'où la création de ce sujet qui à pour but de confronter plusieurs points de vue et tout ceci dans un débat constructif.

Mon point de vue :
Pour moi symfony est un très bon framework, qui contient vraiment pas mal d'outils permettant d'accelerer la production d'une application. Par contre j'ai tout de même l'impression que c'est une usine à gaz dans le sens ou les performances ne sont pas forcément au rendez-vous.
D'après ce que j'ai pu voir un des principaux problèmes de symfony niveau performances et paradoxalement son point fort selon moi c'est à dire propel : visiblement le SELECT * est de mise pour toutes les requetes et dans mon cas ou j'ai une base bien chargée ça pose certains problèmes.

Ensuite je voudrais savoir ce que vous pensez du YML, je ne comprend toujours pas le choix des créateurs pour ce language que je considère plutot "éxotique" et peu commun? De plus il n'est pas très flexible.

Dernier point ou je vais faire un peu de patriotisme, symfony est français ( sensio ) mais la doc en français est quasi inéxistante je trouve ça fort dommage. Je comprend tout à fait que pour se donner de l'ampleur au niveau international un projet se doit d'avoir pour langue principale l'anglais mais je trouve aussi logique de ne pas renier sa langue natale.
Et oui malgrès tous les defauts de notre pays je suis encore fière d'être français

Ceci n'est que mon point de vue incomplet du fait que je ne suis pas encore un expert en symfony il se completera peut etre au fut et à mesure du débat si débat il y a.
A vous de jouer

je lis la doc depuis 2 mois et j'ai fait quelques tests, alors mon sentiment :
_ SELECT * : ça me pose problème aussi, mais en limitant le nombre de résultats, ça doit être bon
_ le Yaml : je trouve ça vachement bien, c'est plus lisible que l'XML, plus organisé qu'un bête fichier .ini . ça parait exotique au début, mais c'est pas si compliqué
_ la doc en français n'est pas complète, mais on y bosse ( _je corrige les fautes d'ortographe, cf le wiki de symfony ) là c'est une question d'engagement de chacun et de prise en main du dossier

voili voila...

A+

Pascal

Assez d'accord avec vous deux et pour ma part je dirais :

- Sur les SELECT * il y a un choix architectural qui offre matière à débat (en effet, pourrait-il en être autrement dans le contexte de symfony ?). Il semblerait également que Creole, la classe d'abstraction de bases de données de Propel, ne soit pas un kador en terme de performances.

- Le Yaml pour être confortable à utiliser t'impose de passer ton éditeur en soft-tabs à 2 sous peine d'avoir de nombreuses erreurs de parsing pas toujours parlantes, ce qui est très pénible.

- Concernant la doc en français, il y a effectivement une lacune béante du projet symfony à ce niveau qui l'empêche de percer dans la communauté francophone et c'est bien dommage. Il faut souligner aussi que le processus de traduction de la documentation semble extrêmement rigide (ils ont fait un workflow pour bouger une virgule ) et décourage les meilleures volontés. Sans doute dans l'optique de vendre du bouquin derrière sur le travail des contributeurs...

Bref, symfony, du (très) bon et du moins bon !

Pour le YAML, c'est une question de goût. Personnellement j'y trouve un avantage très concret : c'est *vraiment* «human-readable» (pas comme ce XML soit-disant lisible, pour peu que le cerveau du lecteur sache faire abstraction de tout le bruit verbeux de ce langage). Je peux même l'envoyer pour validation, le lecteur saura le déchiffrer sans avoir jamais lu la spécification du langage.
Le fait de devoir travailler avec des espaces (l'indentation n'est pas forcément de 2, c'est simplement la convention Symfony qui veut ça, on peut indenter à 4 espaces sans souci aucun) ne m'a pas gêné, j'ai déjà cette habitude (le choix de l'indentation est un débat sans fin car on ne peut plus subjectif, n'ayons pas ce débat ici SVP). Cependant si on bosse avec un vrai éditeur, il y a des chances qu'il propose une config selon le type de fichier, il suffit donc de lui dire de faire une exception pour les .yml.


Concernant la doc, franchement, soyons honnête, l'Anglais est obligatoire dans notre métier, à l'écrit il s'agit d'être bilingue sur l'anglais technique (l'oral compte généralement moins, mais ça aide).
Perso je ne fais aucune différence entre une doc en Français ou en Anglais. J'aurais compris que ce soit bloquant si elle était disponible uniquement en Allemand ou en Mandarin mais là franchement…


Quant au SQL, Propel n'est pas forcément le plus ergonomique des sytèmes d'abstraction (note qu'on peut utiliser Doctrine, ou même ezPdo si ça te chante). Personnellement j'ai eu beaucoup de mal avec… Mais une fois qu'on fait l'effort de se cramponner au système on trouve vite les solutions. Pour faire une requête «custom», c'est vraiment typique. Prenons un exemple concret : j'ai ma table "profil" qui a une relation 1-1 avec ma table "user" et un million de colonnes (au moins), et je ne voudrais que récupérer les informations d'identité (civilite, nom, prenom) pour des user_id donnés.

1. Identifier à quelle classe du modèle cette requête appartient : User ou Profil ? Profil bien sûr. Dans d'autres cas c'est moins trivial, donc il faut toujours se poser la question.

2. Identifier à quelle partie du modèle cette requête appartient : il ne s'agit pas d'un travail sur un seul objet, mais d'une sélection concernant un groupe d'objets. On utilisera donc ProfilPeer (et pas Profil).

3. Nommer la méthode on va l'appeler "getIdentities()" et elle recevra en paramètre un id ou une liste d'ids.

4. Coder ce n'est peut-être pas la partie la plus triviale, et c'est pénible à expliquer car comme je l'ai dit Propel/Creole ne sont pas ce qu'il y a de plus facile à prendre en main, c'est très verbeux dès qu'on sort des sentiers battus, mais ça marche toutefois très bien :
lib/model/ProfilPeer.php

<?php

/**
 * Subclass for performing query and update operations on the 'profil' table.
 *
 * 
 *
 * @package lib.model
 */ 
class ProfilPeer extends BaseProfilPeer
{

  function getIdentities($id) {
    if (!is_array($id)) {
      $id = array($id);
    }
    // Préparer la requête
    $c = new Criteria;
    // Les champs que l'on souhaite sélectionner
    $c->addSelectColumn(self::CIVILITE);
    $c->addSelectColumn(self::NOM);
    $c->addSelectColumn(self::PRENOM);
    // Le critère de sélection (user_id IN (...))
    $c->add(self::USER_ID, $id, Criteria::IN);
    // Exécuter la requête : on récupère un ResultSet
    $res = self::doSelectRS($c);
    // On parcourt le ResultSet pour en extraire les identités
    $identities = array();
    while ($res->next()) {
        // Note : on passe par une classe supplémentaire du modèle, mais rien n'empêche de se passer de cette étape
        $identity = new UserIdentity;
        $identity->hydrate($res);
        $identities[] = $identity;
    }
    return $identities;
  }

}

lib/model/UserIdentity.php

<?php

class UserIdentity 
{

  // Tout le bordel habituel des get/set

  protected $civilite;
  protected $prenom;
  protected $nom;

  function getCivilite() { return $this->civilite; }
  function getPrenom() { return $this->prenom; }
  function getNom() { return $this->nom; }

  function setCivilite($civilite) { return $this->civilite = $civilite; }
  function setPrenom($prenom) { return $this->prenom = $prenom; }
  function setNom($nom) { return $this->nom = $nom; }

  // La vraie fonction intéressante, tirée du code généré par Propel, la méthode hydrate()
  // qui a pour rôle de "remplir" l'objet à partir d'un ResultSet
  // Ordre des colonnes : civilite, nom, prenom (il y a moyen de travailler avec les noms plutôt
  // qu'avec l'ordre, mais comme BasePeer::doSelectRS() marche avec l'ordre des colonnes,
  // c'est plus simple comme ça).

  public function hydrate(ResultSet $rs)
  {
    try {
      $this->civilite = $rs->getString(1);
      $this->nom = $rs->getString(2);
      $this->prenom = $rs->getString(3);
    } catch (Exception $e) {
      throw new PropelException("Error populating UserIdentity object", $e);
    }
  }

}

Voilà, c'est un mauvais exemple, et je comprendrais que celui qui débarque et voit ça se dise «Oh My God ! What The Fuck ! C'est quoi ce machin où il faut pondre 300 lignes et une nouvelle classe pour une pauvre requête ?».
Je lui répondrais ceci dans l'espoir de le rassurer :

• Concrètement, il y a 15 lignes utiles
• Cela répond à un besoin très spécifique du gars qui veut absolument ne pas sélectionner tous les champs de sa table (c'est tout de même assez rare, et si c'est si vital, la plupart du temps ça doit plutôt donner lieu à un refactoring du modèle). Dans le cas général, on n'aurait pas écrit tout ça, et pour récupérer les noms/prénoms des users d'id 1&2&3, on se serait contenté d'appeler "ProfilPeer::retrieveByPKs(array(1,2,3))". Et puis on aurait fait ce type de modification après coup si on avait détecté un goulot d'étranglement du au nombre de champs rapatriés inutilement à cet endroit (il y a donc des chances que ce type d'optimisation n'ait jamais lieu).
• Si on veut coller au tout objet, si on manipule une nouvelle structure de données elle doit avoir sa propre classe. On aurait bien sûr pu se passer de la classe UserIdentity et travailler avec des tableaux associatifs ou des stdClass.
• Si on veut coller à Symfony, les objets du modèle sont tous équipés de getters/setters, forcément ça rallonge (mais ça permet de jolies choses ).

Naholyr, tu as l'air d'avoir beaucoup mieux testé symfony que moi, tu penses quoi des performances générale de l'application?
Penses-tu qu'on peut faire un site grand public à fort traffic basé sur symfony?

En fait actuellement je me dépatouille pas mal avec symfony, même si il m'arrive des fois d'être un peu perdu dans le code et principalement j'ai quelques problèmes à savoir quelles fonctions sont disponibles et où et comment, mais cette question me reste toujours en tête par exemple un site ou peu se retrouver 1000 personnes en même temps.

L'utilisation d'un framework − si on refléchit uniquement en terme de performances − quel qu'il soit (CakePHP, Copix, Symfony, …) apporte toujours un avantage et un inconvénient :

• Une perte globale de performances du au nombre de couches supplémentaires par rapport à une application «maison».
• Un gain de performance au niveau de chaque couche (qui est optimisée pour sa tache particulière)
• Une gestion puissante du cache (en général, en tous cas c'est le cas pour Symfony).

Les deux derniers points ne contrebalanceront jamais le premier, à mon avis il est clair que tu diminues fortement le nombre de connexions simultanées potentielles.

En revanche les optimisations ponctuelles sont plus faciles à réaliser :

• Le code est plus facile à tracer
• Les outils d'optimisation et de cache sont intégrés
• Dans Symfony chaque chose est à sa place, et si on colle à cette philosophie (en ne faisant par exemple jamais une Custom Query ailleurs que dans une méthode du modèle) il est très simple d'optimiser morceau par morceau.

Au final je pense (je ne peux pas certifier et parler d'expérience, le plus vieux site que j'ai réalisé avec Symfony a 3 mois) que le site sera donc bien plus simple à débugger, optimiser, et à faire évoluer. Et qu'une fois optimisé (ce qu'il est simple et sans danger de faire après coup, chose qu'on peut rarement affirmer avec un site «hand-made») il ne nécessitera probablement pas plus de ressources que son homologue bricolé.


Je ne peux absolument pas te donner de chiffres, je ne me suis pas encore amusé à faire deux fois le même site de deux façons différentes mais je n'ai remarqué aucun problème de perfs sur les 3 projets avec Symfony que j'ai pu mettre en prod. Par contre j'ai pu savourer la simplicité du déploiement ainsi que la rapidité du développement (pour peu qu'on ait le manuel à portée de main, ainsi qu'un éditeur comme Eclipse/PDT qui sache faire de l'auto-completion rapidement et intelligemment, parce que c'est vrai qu'on a du mal à s'y retrouver dans l'API au début).

De toute façon tu imagines bien que 1000 visiteurs en même temps, ça dépendra toujours plus du serveur en lui-même que du framework utilisé…

ce qui me gène, c'est le coté verbeux de certaines choses...

par contre la ligne de commande c'est top, surtout pour jouer avec la DB et créer des interfaces admin en quelques secondes

si c'est pas de l'optimisation, ça

A+

Pascal

Je développe aussi depuis quelques mois avec symfony, je l'ai aussi choisi parce que c'était un framework français et parce que c'était le seul à répondre à mes besoins pour un projet particulier.

C'est sûr que Propel est assez lourd... et on est souvent obligé de faire abstraction de la couche d'abstraction ( ) lorsqu'on a besoin de réaliser des requêtes complexes. Mais dans l'ensemble c'est tout de même super agréable de développer avec Symfony .

cf delicious -> symfony (gros trafic, grand public)

côté perfs rien à dire, il suffit de lire la page taggée "performance" de la doc symfony

utiliser le addSelectColumn de Criteria pour ne prendre que quelques champs dans le select

Je n'ai pas encore développé avec un Framework Web mais un jour peut-être...
Cela fait seulement 4 ans que je suis développeur Web et pdt lesquelles années je me suis surtout consacré aux bases du développement.

A vrai dire l'utilisation d'un framework me dérange dans le sens où :
- c'est l'outil de "quelqu'un d'autre" (dans le sens où je n'aurai pas la même fierté que si j'avais développé un projet "entièrement" moi-même)
- c'est l'outil de "quelqu'un d'autre" (dans le sens où je dépend de contraintes de développement autres que celles que je me serai imposées)
- La grande partie des challenges qu'un développeur rencontre disparait en raison des différentes couches de programmation simplifiées par le Framework. Dommage j'adore les challenges, j'adore les difficultés.

Bien sur je conçois parfaitement qu'un framework offre plein d'avantages (gain de temps, sécurité des traitements, souplesse en maintenance etc...), et que ça plairait surement d'en utiliser un. Mais ce qui me bloque aujourd'hui c'est l'impression de m'éloigner du développement "pur" et de l'essence même du développeur Web.

Vous me direz.... j'utilise Smarty et je commence à regarder "prototype" (ajax) bien qu'avant je séparais les couches et développais mes scripts ajax moi-même. Je suis donc de mauvaise foie....
Et peut-être sommes nous, développeurs web, destinés à travailler sur des outils conçus par de grandes compagnies.

Quelque part je suis déçu et inquiet je crois

Ok, je vais télécharger symphony

Si on part par là, pour tout faire toi même, tu dois monter toi même le matériel, concevoir ta propre architecture, coder l'os, puis le serveur http, et enfin coder le site. Et même, le matériel, ce n'est pas toi qui l'a fait, tu devrais pas être bien fier de n'avoir pu graver ton propre processeur, et cabler tes cartes, etc…

Bref, le problème, ce n'est pas de se baser sur quelquechose, quoique tu fasses tu te baseras nécessairement sur quelque chose qui aura été conçu auparavant. La seule question, c'est où est ce que tu fixes ta limite personnelle. A savoir ton juste milieu entre ta fierté personnelle, tes compétences, le temps que cela te prendra, etc…

De plus, je ne pense pas qu'il faut voir le fait d'utiliser des frameworks ou CMS comme rabaissant ...

La majorité des appels d'offre demandent maintenant de faire appel à ce genre d'outils.
que ce soit Symfony, Typo3, Drupal, ou autre, ils ont été testé, réfléchis, et utilisés; ils ont fait leur preuve, et c'est une valeur ajoutée à ton développement.

Coder soit même, ajoute peut-être un peu de fiertée, mais donnera une application plus difficile à maintenir par les autres, peut-être moins évolutive, ...

Le web évolue, de plus en plus on réutilise. Après, il faut savoir se fixer des limites.
La question c'est "Est ce que mon projet demande vraiment cette usine à gaz ?"

Utiliser Symfony pour coder un simple système de vote par exemple, ok, on est dans l'excès.
Utiliser Symfony pour un site qui va demander une bonne structure, des multitudes de modules, ... c'est plus que raisonnable

Bonjour,

J'ai un probleme avec "addSelectColumn", j'espère que vous allez pouvoir m'aider.
J'ai fait comme votre morceau de code :

$critRequete = new Criteria();
$critRequete->addSelectColumn(ProjetPeer::CTR_ID);
$critRequete->add(ProjetPeer::CTR_ID, $ctr);
$this->listProjet = ProjetPeer::doSelectRS($critRequete);

mais je ne vois pas où est mon erreur sachant que si je met la ligne avec le addSelectColumn en commentaire, cela fonctionne.
Pourriez-vous m'aiguillez svp ?
Merci

Pour le YAML, c'est une question de goût. Personnellement j'y trouve un avantage très concret : c'est *vraiment* «human-readable» (pas comme ce XML soit-disant lisible, pour peu que le cerveau du lecteur sache faire abstraction de tout le bruit verbeux de ce langage). Je peux même l'envoyer pour validation, le lecteur saura le déchiffrer sans avoir jamais lu la spécification du langage.
Le fait de devoir travailler avec des espaces (l'indentation n'est pas forcément de 2, c'est simplement la convention Symfony qui veut ça, on peut indenter à 4 espaces sans souci aucun) ne m'a pas gêné, j'ai déjà cette habitude (le choix de l'indentation est un débat sans fin car on ne peut plus subjectif, n'ayons pas ce débat ici SVP). Cependant si on bosse avec un vrai éditeur, il y a des chances qu'il propose une config selon le type de fichier, il suffit donc de lui dire de faire une exception pour les .yml.


Concernant la doc, franchement, soyons honnête, l'Anglais est obligatoire dans notre métier, à l'écrit il s'agit d'être bilingue sur l'anglais technique (l'oral compte généralement moins, mais ça aide).
Perso je ne fais aucune différence entre une doc en Français ou en Anglais. J'aurais compris que ce soit bloquant si elle était disponible uniquement en Allemand ou en Mandarin mais là franchement…


Quant au SQL, Propel n'est pas forcément le plus ergonomique des sytèmes d'abstraction (note qu'on peut utiliser Doctrine, ou même ezPdo si ça te chante). Personnellement j'ai eu beaucoup de mal avec… Mais une fois qu'on fait l'effort de se cramponner au système on trouve vite les solutions. Pour faire une requête «custom», c'est vraiment typique. Prenons un exemple concret : j'ai ma table "profil" qui a une relation 1-1 avec ma table "user" et un million de colonnes (au moins), et je ne voudrais que récupérer les informations d'identité (civilite, nom, prenom) pour des user_id donnés.

1. Identifier à quelle classe du modèle cette requête appartient : User ou Profil ? Profil bien sûr. Dans d'autres cas c'est moins trivial, donc il faut toujours se poser la question.

2. Identifier à quelle partie du modèle cette requête appartient : il ne s'agit pas d'un travail sur un seul objet, mais d'une sélection concernant un groupe d'objets. On utilisera donc ProfilPeer (et pas Profil).

3. Nommer la méthode on va l'appeler "getIdentities()" et elle recevra en paramètre un id ou une liste d'ids.

4. Coder ce n'est peut-être pas la partie la plus triviale, et c'est pénible à expliquer car comme je l'ai dit Propel/Creole ne sont pas ce qu'il y a de plus facile à prendre en main, c'est très verbeux dès qu'on sort des sentiers battus, mais ça marche toutefois très bien :
lib/model/ProfilPeer.php

<?php

/**
 * Subclass for performing query and update operations on the 'profil' table.
 *
 * 
 *
 * @package lib.model
 */ 
class ProfilPeer extends BaseProfilPeer
{

  function getIdentities($id) {
    if (!is_array($id)) {
      $id = array($id);
    }
    // Préparer la requête
    $c = new Criteria;
    // Les champs que l'on souhaite sélectionner
    $c->addSelectColumn(self::CIVILITE);
    $c->addSelectColumn(self::NOM);
    $c->addSelectColumn(self::PRENOM);
    // Le critère de sélection (user_id IN (...))
    $c->add(self::USER_ID, $id, Criteria::IN);
    // Exécuter la requête : on récupère un ResultSet
    $res = self::doSelectRS($c);
    // On parcourt le ResultSet pour en extraire les identités
    $identities = array();
    while ($res->next()) {
        // Note : on passe par une classe supplémentaire du modèle, mais rien n'empêche de se passer de cette étape
        $identity = new UserIdentity;
        $identity->hydrate($res);
        $identities[] = $identity;
    }
    return $identities;
  }

}

lib/model/UserIdentity.php

<?php

class UserIdentity 
{

  // Tout le bordel habituel des get/set

  protected $civilite;
  protected $prenom;
  protected $nom;

  function getCivilite() { return $this->civilite; }
  function getPrenom() { return $this->prenom; }
  function getNom() { return $this->nom; }

  function setCivilite($civilite) { return $this->civilite = $civilite; }
  function setPrenom($prenom) { return $this->prenom = $prenom; }
  function setNom($nom) { return $this->nom = $nom; }

  // La vraie fonction intéressante, tirée du code généré par Propel, la méthode hydrate()
  // qui a pour rôle de "remplir" l'objet à partir d'un ResultSet
  // Ordre des colonnes : civilite, nom, prenom (il y a moyen de travailler avec les noms plutôt
  // qu'avec l'ordre, mais comme BasePeer::doSelectRS() marche avec l'ordre des colonnes,
  // c'est plus simple comme ça).

  public function hydrate(ResultSet $rs)
  {
    try {
      $this->civilite = $rs->getString(1);
      $this->nom = $rs->getString(2);
      $this->prenom = $rs->getString(3);
    } catch (Exception $e) {
      throw new PropelException("Error populating UserIdentity object", $e);
    }
  }

}

Voilà, c'est un mauvais exemple, et je comprendrais que celui qui débarque et voit ça se dise «Oh My God ! What The Fuck ! C'est quoi ce machin où il faut pondre 300 lignes et une nouvelle classe pour une pauvre requête ?».
Je lui répondrais ceci dans l'espoir de le rassurer :

• Concrètement, il y a 15 lignes utiles
• Cela répond à un besoin très spécifique du gars qui veut absolument ne pas sélectionner tous les champs de sa table (c'est tout de même assez rare, et si c'est si vital, la plupart du temps ça doit plutôt donner lieu à un refactoring du modèle). Dans le cas général, on n'aurait pas écrit tout ça, et pour récupérer les noms/prénoms des users d'id 1&2&3, on se serait contenté d'appeler "ProfilPeer::retrieveByPKs(array(1,2,3))". Et puis on aurait fait ce type de modification après coup si on avait détecté un goulot d'étranglement du au nombre de champs rapatriés inutilement à cet endroit (il y a donc des chances que ce type d'optimisation n'ait jamais lieu).
• Si on veut coller au tout objet, si on manipule une nouvelle structure de données elle doit avoir sa propre classe. On aurait bien sûr pu se passer de la classe UserIdentity et travailler avec des tableaux associatifs ou des stdClass.
• Si on veut coller à Symfony, les objets du modèle sont tous équipés de getters/setters, forcément ça rallonge (mais ça permet de jolies choses ).

Pour poser une question, il faut créer un nouveau sujet, laeti31.

Si tout le monde s'amuse à poster dans d'ancien posts, on ne s'en sort plus.