Bonjour, Un test de charge permet d'identifier les goulots d'étranglement, et aussi d'avoir un référentiel de temps de réponse qui peut te servir d'étalon pour tes optimisations d'architectures. (par exemple avec JMeter tu peux tester les webservices cf. http://s.apache.org/kF )
Sinon, il faut aussi penser aux optimisations de la couche OS (optimisations TCP, kernel), et des différents briques logiciels (en particulier Apache et MySQL). Si tu laisses les valeurs par défaut, cela ne risque pas d'être hautement performant. Les composants comme Varnish ou memcache permettent en effet d'améliorer les choses, mais une mauvaise configuration (standard ou non-orientée performance) fera plus de mal. Par ailleurs, trouver un goulot entre l'utilisateur et le fond du backend devient de plus en plus difficile avec l'ajout de couches (load balance ip, reverse proxy cache, frontaux web/php, cache code, base, etc). Pour résumé, dans les points à vérifier : * faire un petit test de charge (par trop d'utilisateur) pour avoir une référence * optimisation tcp / kernel de l'OS (il y a pas mal d'exemple sur Internet sur les choses importantes. Ce redbook pour Linux est plutôt bien http://www.redbooks.ibm.com/abstracts/redp4285.html?Open= * faire le même test de charge et comparer * optimiser les briques logiques : Apache (nb thread, activation mod_cache, mod_expire, mod_deflate entre autres), memcache (compression des flux si sur serveurs distant), varnish (règles de cache optimales), mysql (augmenter la mémoire allouée pour monter les tables en mémoire entre autre) * faire le même test de charge et comparer L'idée est de mesurer l'amélioration. A+ Milamber Le 05/09/2011 09:28, Richard DEMONGEOT a ecrit : > On Mon, 5 Sep 2011 11:15:02 +0200, "vincent finet" > <vincent.fi...@viveris-asr.fr> wrote: > >> Merci pour vos réponses avisées. >> > Re, > > >> Je ne sais en fait pas vraiment ou se situe le goulot. >> En l'état les perfs sont bonnes et l'architecture bien dimensionnée >> > (tout > >> les indicateurs aux verts dans Nagios). >> >> J'aimerai cependant encore améliorer la chose pour que l'application >> charge plus vite et pour pouvoir faire face à une charge plus >> > importante. > >> En pratique cela veut dire : >> --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs >> backend ? autre ?) >> --> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? >> mmcache ? autre ? / optimiser Mysql : ?) >> > L'idéal serai de faire tout une série de bench. > > Timers à tire la rigo dans ton appli (et donc logs, soit sur du SQL soit > sur du texte standard). > > Et coté client, toute une batterie de test avec firebug, par exemple, qui > va te définir les parties lentes à charger. > > Ainsi, tu verra, que par exemple, la page "toto.php" met 2 dizièmes, là ou > la page tutu.php en met 12. Dans ce cas, l'optimisation passe par le code. > > Si les lenteurs sont similaire pour un type de page, voir si elles sont > "normales" ou dans la moyenne haute par rapport aux autres sites. > > Ces tests (y compris avec des apache bench à tire la rigo / du wget ou > autre / un parsing de site accéléré / toussa) te permettront d'identifier > le bottleneck de l'infra, et donc de savoir ou travailler. > > >> Cdt >> > Cdt, > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
