ok dans ce cas je comprends par contre vu cette difference de perfs que l'on soit pratiquement obligé a etre sous Linux( car oui franchement je voudrais pas travailler sur un truc qui mouline)Citation:
Envoyé par bilbot
Version imprimable
ok dans ce cas je comprends par contre vu cette difference de perfs que l'on soit pratiquement obligé a etre sous Linux( car oui franchement je voudrais pas travailler sur un truc qui mouline)Citation:
Envoyé par bilbot
Je n'ai pas testé sous Windows et je ne compare pas à SF1 qui était un veau.Citation:
Envoyé par bilbot
Sous Linux avec une machine sous Atom / 4G de ram qui me sert de serveur, une simple page qui ne charge pas la base de données, j'ai un temps moyen de 600 ms à plus d'une seconde avec 6,5Mo de conso de mémoire.
+1Citation:
Envoyé par MaitrePylos
J'espère aussi que le temps investit dedans ne soit pas perdu, à cause de passage en version qui casse tout (le framework perdrait son utilité si il devient trop lourd à maintenir). Ou tout simplement à cause d'une perte de productivité.
Pour l'instant j'en suis à la barrière d'acquisition de SF2, donc la productivité est forcément réduite vue que je passe plus de temps à rechercher et tester qu'à avancer. Vivement que ça s'inverse quand j'aurais un peu plus de pratique :)
Avez-vous remarqué un gain de productivité une fois les reflex/pratiques en place ?
Pour Zend, rien n'empêche de l'utiliser dans SF2. Par contre, ça va consommer pas mal au niveau de la ram avec Zend_Date.
En mode production ou dev ? Si c'est en prod je pense que tu as un soucis de paramétrage (APC/génération du cache...)Citation:
Envoyé par FrontLine
pareil petit précision pour Doctrine, personne n'est obligé de faire de l'ORM, On peut très bien faire ces propres requêtes
Sous Windows, faut bien configurer APC et utiliser ApcUniversalClassLoader, sinon ça sert pas a grand chose ;)
ApcUniversalClassLoader il faut l'indiquer dans autoload.php, à la place de UniversalClassLoader ?
edit: effectivement, c'est expliqué ici : http://symfony.com/doc/2.0/book/performance.html
Oups effectivement, niveau temps en mode production c'est mieux, niveaux mémoire c'est encore trop : Time : 0.191 sec | Mem usage : 4,35 Mo (Mem peak : 5,10 Mo)Citation:
Envoyé par bilbot
Mise à part un template qui fait 3 héritages (d'autres templates) il n'y a rien de spécifique. Le template est simple quelques lignes, un top barre et le contenu.
Sinon avez-vous remarqué un gain de productivité une fois les reflex/pratiques en place ? C'est intéressant de savoir car c'est un des principaux buts recherché au final :)
Je voulais juste partagé un lien d'un tuto qui me parait pas mal.
J'en suis a l'etape 2 et pour l'isntant ca ressemeble furieusement a un jobeet.
En fait, je suis la méthode et je construis les pages de mon propre site web du coup.
http://keiruaprod.fr/symblog-fr/
Benchmark accablant pour symfony2 : https://github.com/seedifferently/th...ework-shootout
Plus ça va et plus je me dis que je perds mon temps avec SF2 ... surtout au niveau de la configuration trop chronophage et certaines choses à la Java mais en PHP (ça n'a pas de sens). Je cherche un autre mais j'ai l'impression qu'il n'y a pas "the framework" qui me convienne.
A part FuelPHP mais il est encore un peu trop jeune.
Ce genre de test sur un Hello World à toujours été ridiculeCitation:
Envoyé par FrontLine
https://github.com/alexandresalome/B...For-Benchmarks
Encore une fois je rappelle qu'il y'a 2 choses dans Symfony : les Composant et le Framework.
Si le framework ne vous convient pas, il y'en a d'autre comme Silex par exemple, et les excellent articles de Fabien pour créer un Framework selon ses besoins : http://fabien.potencier.org/article/...ponents-part-1 :ccool:
Bonjour,
Cela fait quelques jours que je mets en pratique le tutorial symfony 2 que j'ai mis un peu plus haut dans un projet personnel. (6-7 heures de boulot pour l'instant)
J'ai un peu utilisé symfony 1 dans mes expériences professionnelles précédentes.
Alors, premières impressions sur ce frameworks.
Dans l'ensemble il est assez complexe à appréhender et la documentation sur le site de symfony est déplorable. C'était leur plus grand point fort, au travers de jobeet qui quoi qu'on en dise remplaçait 10 000 pages d'API. Je ne pense pas avoir été le seul auquel se boite a dit : fais jobeet les 2 premières semaines, ca ira mieux après. On y apprenait des bonnes pratiques et surtout on abordait tous les points méthodiquement, de façon mémorisable permettant de retrouver facilement une information ou une syntaxe que l'on aurait pu oublier.
Pour quelqu'un comme moi qui ne retient rien et qui me réfère toujours à la doc, c'était pratique.(en particulier les lignes de commandes)
Malgré tout, une fois que l'on a passé 1 heure à chercher le bon tuto sur le net, on peut commencer à découvrir le frameworks.
Si comme je le soulignais il est difficile à appréhender, entre autre par son avalanche de thèmes et de concepts hautement inutiles dans 95% des sites web. (Qui a besoin de la flexibilité des bundles pour faire un site de base... lorsque les tutoriels conseille tout bêtement de recréer un 2nd projet si l'on a une autre application à faire...)
Il n'en demeure pas moi intéressant et j'ai bien aimé le découpage avec app d'un coté et sources de l'autre.
J'ai un peu pesté au début parce que j'avais mis un nom de projet long et un nom de Bundle tout aussi long, avant de m'apercevoir qu'on devait les retaper 15 fois par page. J'aurais limite envie de mettre maintenant :
Application A.
bundle : BBundle.
Ca me ferait gagner un max de temps et limiterai beaucoup les erreurs de frappe.(on perd en lecture, mais comme ce sont 2 informations proprement inutiles , on ne va pas se fâcher pour si peu...)
Pour les entités et leur génération, j'ai apprécié d'avoir le choix de me passer des annotations. je suis peut être moi aussi de la vieille école, mais j'aime mieux séparer les choses qui n'ont rien à voir entre elles. Un schéma objet et un schéma BDD n'ont pas vocation à être ensemble dans un fichier et je pense que rien que l'idée qu'un schéma de BDD puisse être délégué a des commentaires éparpillé de partout montre bien le dédain qu'on montre pour le design de ce schéma.
C'est dommage quand on pense qu'il s'agit du cœur de l'application et de ce qu'il y a de plus critique dans celle ci.
Bon, c'est habituel dans le monde de la programmation, java et hibernate avaient "innové" avec les annotations, il fallait bien que des moutons suivent le troupeau.
Je pense que si je dois demander de l'aide sur un forum, les gens apprécieront de voir mon fichier en yaml plutôt que ma classe avec toutes mes fonctions personnelles qui parasitent l'information.
J'ai donc apprécié le fait de pouvoir utiliser les fichiers YAML qui centralise mon schéma et qui en plus ont le bon gout de mettre à jour TOUTES les entités en une seule ligne de commande et non une par une. (j'ai apprécié de pouvoir faire une commande automatique sur eclipse pour me passer de la console).
Pour le reste, je me fait plaisir. Les découpages du codes sont a peu prés logiques après quelques heures à travailler dessus, on prend vite le truc pour retrouver l'information et les bugs à droite ou à gauche.
Je reste donc sur une bonne impression finale, malgré la première étape qui m'a très sérieusement fait hésité entre symfony 2 et la version 1.4 du frameworks.
Si Sensio labs ne corrige pas cette erreur pour aider les gens lors de leur apprentissage, cela ne m’étonnerai pas que Symfony 1.4 soit forké et qu'une autre société lui donne une seconde vie.
Pour tous ceux qui ne souhaitent pas découper leur application en Bundles comme le préconise la structure de Symfony, découpage qui s'avère parfois fastidieux et peu cohérent pour des projets contenus, il existe une alternative : KnpRadBundle !
Vous pouvez toujours utiliser des bundles tiers dans vendors, mais les sources de votre application retrouvent une structure plus classique.
Un petit aperçu :
http://www.developpez.net/forums/att...1&d=1330963843
L'image de marque de symfony est nulle ,ça fait framework pour ado boutoneux.
Que c'est constructif !!! Merci pour ta participation.Citation:
Envoyé par sybil
Personellement, je me suis servi de trois frameworks : codeigniter, zend and symfony2.
J'aime sf2 parce que pour moi il a la simplicité de codeigniter, mais la puissance de zend. Il est vrai que la prise en main est un peu lente, mais une fois les principes compris, on navigue très facilement dans le projet.
Le découpage d'application préconisé semble difficile au départ (surtout comparé à CI, ou tout tient dans une dizaine de répertoires... ;) ), mais c'est remarquablement logique. Maintenant, je ne cherche même plus, c'est devenu une seconde nature pour moi :) (ça ne fait que 3 semaines que je suis sur sf2 en passant ;))
Et pour FrontLine : si l'empreinte mémoire de SF2 est trop grande à ton gout, ne t'approche surtout jamais de zend... Tu en ferais des syncopes ;)
Je ne peux qu'approuver. Les quelques discussions que j'ai pu avoir avec des développeurs (en particulier web) dénotent pas mal de mépris pour la base de données. N'importe quel schéma bancal fait l'affaire. On récupère les erreurs au niveau du programme.Citation:
Envoyé par pmithrandir
...Ce qui est parfois à l'origine d'une évolutivité de l'application plutôt faible et d'un code alambiqué.
Je vois clairement pas le problème des annotations pour définir le schéma de base de données, en quoi méprise t-on la base de données. C'est un mécanisme utilisé en Java par exemple, dans d'autre langage tels que ruby ça utilise d'autre mécanisme propre au langage mais le resultat est le même. Il faut pas voir les annotations comme ce qui définit ton schéma de base de données, mais plutôt permettre à l'ORM de faire facilement le mapping entre la base de données et un modèle objet, mais rien n'empêche de se passer d'ORMCitation:
Envoyé par fatbob
C'est surtout un choix technique que de formater son schéma en fonction de l'ORM utilisé, et non privilégier une structure de BDD parfaitement bien formée.
Au vu des coûts de développement, ça peut vite se révéler judicieux. J'y étais réticent au début et finalement, vu le temps gagné en développement, j'accepte totalement de formater mon schéma à la mode de Doctrine2.
Pour expliciter mon aversion envers l'utilisations des annotations, je vais essayer de developper un peu mes arguments.
La base de données a une structure à elle, des contraintes basées sur son fonctionnements, et souvent, elle ne ressemble pas au modele objet ideal.
On va par exemple devoir morceler beaucoup plus pour economiser de la place, ou stocker plus inteligement certaines choses. Pour cela, un tour sur le forum conception BDD vous donnera des informations.
Dans 80% des petits projets web, ca ne change rien. Mais dés que l'on arrive a des tables qui contiennent plus d'un millions de données, on court le risque de voir ses performances s'écrouler d'un seul coup sans raison. (en fait, on dépasse les capacités serveurs, et on passe en mémoire disque le plus souvent, donc on a un site qui ne fonctionne plus)
Un exemple donné par sqlpro, l'enregistrement d'un email.
naturelement, en objet, vous créez une string, et vous aurez tendance a utiliser un varchar en BDD.
Sauf que si vous voulez être un peu puriste, et optimiser en très haut niveau, vous pouvez découper votre email en 2 informations :
L'identifiant
le fournisseur.
Exemple :
test014235@hotmail.com
Vous conservez l'identifiant, mais le hotmail.com va être stocké dans une table a part, et vous ne conserverez que l'identfiant qui permet d'y arriver. Sur 10 millions d'utilisateur avec 2 ou 3 emails par personnes, la différence sera tout a fait notable.
Si un jour vous devez envoyer un email spécifique a tous les utilisateurs d'hotmail(par exemple pour signaler unproblème juste avce eux) vous le ferez en outre de facon plus simple.
Bref, c'est un peu extrème, mais c'est le genre de contrainte que l'on peut avoir en BDD.
Le problème des annotations, c'est qu'elles incitent fortement l'utilisateur a appliquer un shéma objet en BDD. Et ca ne sera pas obligatoirement sencé. A coté de cela, un shéma en yml, se détache de cette reflexion, et donc permet de génerer ses objets en fonction de la BDD, et non le contraire.
On aime ou on aime pas, mais en général, les développeurs actuels ont des notions catastrophiques en BDD, et ne s'en préocupent pas. On note souvent un mépris pour la BDD, qui fait bien plaisir aux consultants dans ce domaine qui se font des corones en or massif. En effet, le jour ou l'appli plante, on répare... le jour ou la BDD est corrompue, on a perdu des données clients... et on est dans la merde.
Les annotations sont donc pour moi, une fausse bonne idée. Elle incite a appliquer des principes objet a une bdd qui en utilise d'autre, et ces annotations ont déjà fait pas mal de dégat en java en éloignant les dev de la conception de BDD. Reprendre une idée comme celle la allors que symfony 1 était centrée sur les données... me parait aller dans la mauvaise direction.
D'un point de vu pratique, sur un forum, je préfère netement qu'on me colle un shéma YML de 30 lignes, plutot qu'une floppée de classes... Je comprendrais mieux la structure et je n'aurai pas de code parasite pour ralentir ma lecture.
Bonjour, que pensez vous au niveau performance,
J'ai installer un symfony2 avec un hebergement mutualisé pro chez OVH et ça rame à mort, avec Zend ce ne ramais pas autant , mais bon je compare zend1 face a symfony2.
Il y a t' il des personnes qui ont constaté que ça fait beaucoup ramé après l'appelle de la même page, la première fois étant normal.