Simple Entrepreneur

17 commentaires à propos de “Comment bien gérer la montée en charge d’une application web ?” :

1. Mes techniques :

   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 çà.

   Pti-seb le 11 mars 2008 à 09:05 (#1)

2. et la montée de charge de Loomiz dans tout ca?

   Thomas le 11 mars 2008 à 09:18 (#2)

3. Salut Stéphane,

   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.

   Gilles le 11 mars 2008 à 11:31 (#3)

4. Comme le dit Pti-seb il y a déjà beaucoup à faire au niveau d’une seule machine.
   Les gros serveurs actuel (Quadri Xeon etc.) représentent une capacité de traitement que peux d’applications correctement optimisées sont capable de mettre à genoux.

   mrboo le 11 mars 2008 à 11:40 (#4)

5. Merci pour ces slides, elles ont en plus pour mériter de prouver que les plateformes LAMP sont utilisées par de grands noms d’Internet. Certains programmeurs ont tendance à trop sous estimer le couple PHP MySQL.

   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…

   eMeRiKa le 11 mars 2008 à 13:15 (#5)

6. Hello,

   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

   Cedric Sadai le 11 mars 2008 à 17:50 (#6)

7. Salut 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.

   Gilles le 11 mars 2008 à 21:38 (#7)

8. Re Gilles,

   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

   Cedric Sadai le 11 mars 2008 à 23:10 (#8)

9. Fais-moi signe quand tu auras écrit cet article Pti-Seb !

   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).

   Stéphane le 12 mars 2008 à 07:58 (#9)

10. Cédric, au contraire, je trouve les changements assez importants et il y a encore pas mal de points importants en suspend (à ma connaissance) : ORM maison, évolutions importantes dans les ORM existants, admin generator… Sans parler des plugins qui, pour la plupart, ne seront plus compatibles (il faudra alors refactoriser et repasser par une phase de test pour assurer un minimum leur solidité). Bref, c’est pas la petite migration. De plus, je n’aime pas travailler sur du code instable qui risque de bouger toutes les semaines (j’en ai déjà fait les frais sur un projet et ça a été une perte de temps assez considérable).

    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.

    Gilles le 12 mars 2008 à 10:41 (#10)

11. Bonjour,

    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 !

    minty le 12 mars 2008 à 10:43 (#11)

12. On distingue deux type d’optimisation :
    - l’optimisation de conception,
    - l’optimisation technique.

    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).

    Romain le 12 mars 2008 à 17:16 (#12)

13. Gilles> J’éspère que ce ne sont pas mes billets et nos récentes discussions qui te font t’écarter de la lumiè^H^H^H^H^H de Symfony

    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

    NiKo le 16 mars 2008 à 21:28 (#13)

14. D’autres présentations du même genre : http://highscalability.com/links/weblink/24 (Amazon, eBay, Feedburner, Google…)

    Gore le 19 mars 2008 à 14:03 (#14)

15. Une autre vidéo très intéressante de l’architecte d’eBay qui explique les guidelines pour designer une architecture capable d’encaisser 44 milliards de requêtes SQL par jour.
    La vidéo dure une heure et elle vaut quelques milliers d’euros de consulting…

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

    Jerome le 2 avril 2008 à 20:51 (#15)

16. Super, merci pour tous ces liens !

    Stéphane le 7 avril 2008 à 11:42 (#16)

17. Super article. Toutes ces présentations sont une vrai mine d’or.
    Il y a aussi ce bouquin qui semble être une référence.

    Nicolas Cynober le 23 avril 2008 à 11:58 (#17)

2 rétroliens à propos de “Comment bien gérer la montée en charge d’une application web ?” :

1. le blog à Ollie » Liens du jour
   Le 12 mars 2008 à 23:18
2. Revue de Presse Xebia par J2EE, Agilité et SOA : Le blog de Xebia France
   Le 17 mars 2008 à 18:19

Abonnement

Recevoir les nouveaux articles par RSS

Recevoir les nouveaux articles par email

Sauvegarde

Ajouter ce blog à ses favoris Technorati

Partenaires

Derniers commentaires