http://www.infoq.com/presentat.....principles

Symfony 1.0 est suffisamment stable, maintenu et fonctionnellement riche pour faire face à de nombreux projets, du plus humble au plus monstreux bloatware. La 1.1 n’est pour le moment ni sortie, ni documentée, donc partir dessus doit vraiment être une décision prise en connaissance de cause, sinon mur assuré. J’entends par là que cela implique de suivre la timeline du Trac de Symfony au jour le jour et bien connaître le coeur du framework, ce qui n’est bien évidemment pas à la portée de tout le monde, que ce soit en termes de temps ou de compétence

L’optimisation technique est découpable en plusieurs parties : physique, architecturale, n-tiers, etc.

Il y a certainement une étape intermédiaire entre une optimisation prématurée, et ne pas prévoir de montée en charge du tout.
Il est absolument nécessaire d’avoir une réflexion préalable avant même de commencer à coder : savoir quelle taille auront les champs de la base de données, utiliser des variables globales n’étant définie qu’une seule fois dans le code, etc.
Cela peut sembler tout à fait “normal” pour des concepteurs aguerris, mais dans la pratique on peut se rendre compte que seul 20% des développeurs/concepteurs y pensent (approximation estimée selon mon expérience).

Hormis les incontournables chantiers autour de l’architecture physique (cluster, replication, fail-over etc…) le chantier de perf doit être intégré au projet dès le lancement de celui-ci avec des objectifs, nb de sessions, traffic etc. Bien souvent, les tests de perfs sont menés à la fin du projet une fois le fonctionnel terminé, sur des campagnes souvent très courtes qui mettent rapidement en lumières des manques dans la façon de coder, dans le respect des standards, sans intégration continue et de test unitaires… L’appli est viable, mais dès les premiers pics de charge, le hdw ne monte pas en charge et les temps de réponse s’allongent… et pour être en plein dedans en ce moment, avec la reprise d’un projet mal orienté sur les perfs, plutôt le chantier perf est adressé mieux le projet se porte en bout de course :-).

Bon courage à tous sur vos prochaines applis !

A l’heure actuelle, pour le démarrage d’un nouveau projet, soit on part sur du 1.1 direct mais avec perte de code / temps difficile à estimer si la phase de dev est courte (pour une phase dev long, c’est pas vraiment important); Soit, comme tu as dit, on part sur du 1.0 (puisque maintenu) mais en prenant en considération le futur refactoring (donc, double travail). Les “features” de la 1.1 sont tellement alléchantes que ça ne donne plus envie de développer en 1.0 :p Pour moi, le choix serait vite fait : direct en 1.1, si j’avais du temps devant moi.

Merci pour le lien vers ton article (et j’aime bien le design de ton site).

Stéphane, Symfony propulse aussi Yahoo! Bookmarks

Bonne journée.

Pourquoi crois-tu que je publie ce genre d’article Thomas ? J’y travaille.

Tu le sais sûrement déjà Gilles, mais Loomiz est basé sur Zend Framework. Au niveau applicatif, je le recommande vivement. Mais je rejoins complètement Cédric dans son argumentation (particulièrement en fonction des compétences à ta disposition). Symfony me semble également un très bon choix (et apparemment, c’est le framework qui propulse la prochaine version de Delicious).

Je ne comprends pas ce qui t’inquiètes vraiment avec Symfony 1.1. A vrai dire, le seul changement notable est l’aspect formulaires, et encore, la compatibilité antérieure est (me semble t-il) assurée.

Tu as une solution alternative: faire le choix délibéré d’une branche, disons la 1.0, et y rester. En effet, Sensio assure la maintien des versions précédentes, tu pourras donc toujours bénéficier des corrections de bugs sur la 1.0 meme si Symfony en sera à la 3.0 (pour la simple et bonne raison à mon avis que nombre de leurs clients ont été développés en 1.0 et qu’ils doivent en assurer la maintenance).

Niveau technique, tu peux jouer avec svn:externals pour taper dans des librairies qui se mettent automatiquement à jour à chaque changement sur le coeur de symfony (tu peux y fixer une version, comme la branche 1.0). J’ai relaté cette technique dans mon blog à cette adresse: http://www.sadai.net/installer-symfony-avec-svn

Sinon à défaut tu as raison, les choix se valent. Personnellement, je ferais le choix selon les compétences des dev qui m’entourent, et qui pourraient ainsi m’aider en cas de problème.

Cédric

Je connais déjà bien Symfony mais le passage en 1.1 (enfin, 2.0), actuellement en plein développement, et la future orientation du framework me donnent à réfléchir. Je dois développer dans l’immédiat et dans cet immédiat, je ne peux pas choisir Symfony. Idem pour Django dont j’attends avec impatience la sortie de la stable.

Du coup, il me reste Rails et Zend Framework. Comme je ne suis pro-rien-du-tout, que je me sens “à l’aise” en Ruby comme en PHP, le choix est un peu complexe. Mais je pense que je vais partir sur Zend Framework pour le moment et pourquoi pas migrer mon application sous un framework Ruby (quand le langage intégrera une solide VM pour booster un peu les performances) ou Symfony 2.0 par la suite (si vraiment il y a besoin).

Bonne soirée à toi.

Slides incontournables dans le petit monde de l’entrepreneuriat technologique.
Ce qui en ressort c’est qu’il faut avoir conscience de ces différents leviers d’optimisation, mais ne pas forcément les mettre en place tout de suite (trop couteux, trop long). Commencer par optimiser son code, mettre en place des systèmes de cache (cache fichier, memcached, voire squid), avant de toucher aux load balancers.

Gilles, ton choix techno doit dépendre de tes compétences, de la facilité de recrutement de dév sur ta techno clé, de la communauté des développeurs, en + des arguments purement techniques (a savoir vitesse d’execution etc…). Zend est un framework MVC solide, même si j’ai une grosse préférence personnelle pour Symfony (tu devrais peut etre creuser cette piste d’ailleurs, cf www.symfony-project.com).

Cedric

Gérer la montée en charge et l’administration d’un serveur est un vrai problème surtout lorsqu’on n’y connais pas grand chose en linux et en admin réseau. J’en ai d’ailleurs fais les frais récemment…

Intéressant mais parfois un peu trop “vague” (un peu logique, ce sont des slides… Rien ne remplace la vraie conférence ou le recueil de retour / techniques / subtilités sur le terrain). C’est un domaine vraiment technique et souvent même casse-tête. Bon courage pour Loomiz

Pour un projet, j’hésite actuellement entre Ruby on Rails et Zend Framework (Django j’aime beaucoup mais j’attends la version stable). J’ai une préférence pour le langage Ruby et le framework Rails (mais j’aime tout autant PHP… Ce n’est qu’une subtile préférence à la “perfectionniste” pas du tout objectif) mais vu les performances de Ruby et la galère pour rendre le tout scalable, ça me rebute pas mal. Je vais donc certainement m’orienter vers Zend Framework, certainement plus “facile” à scaler (meilleurs performances de PHP, flexibilité extrême du framework, plus de retours, produits Zend efficaces si besoin…). D’ailleurs si un lecteur utilise Zend Framework en production sur un site assez important, un retour serait le bienvenu

Bonne journée.

1/ coté serveur :
- compiler Apache
- revoir la config pour augmenter le nombre de connexion simultané, choisi entre prefork ou mpm selon les besoins.
- utiliser mod_cache pour faire du cache
- utiliser mod_deflate pour faire de la compression (sur les css, js, html)

2/ coté application :
- faire du cache également
- bien fermer les connexions vers la base de données quand on en a plus besoin
- optimiser le code

Après on pourra effectivement poussez l’architecture plus loin en mettant en place de la répartition de charge (heartbeat fait bien ce genre de chose sous Linux).

Un jour faudra que j’écrive des articles sur tout çà.