OVH Community, votre nouvel espace communautaire.

Optimisation performances architecture serveur Web


Bipbip
05/09/2012, 15h07
Tu as essayé avec ce type de configuration ?

http://blog.brigato.fr/2011/12/24/wo...pu1gb-ram-vps/

Ça fait un peu usine à gaz mais ça s'adapte très bien à toute appli fonctionnant en PHP.

Perso j'utilise Varnish avec Lighttpd. C'est plus simple à mettre en place et c'est kif-kif-bourricot question perf pures (si pas plus performant).

Math33
05/09/2012, 09h52
Apache en worker MPM + FCGI consomme bien plus de RAM qu'un Nginx avec quelques workers pour au moins les mêmes performances.
Dans un contexte de virtualisation, mieux vaut essayer d'éviter les gaspillages de RAM même si la sur-allocation peut aider à ne pas trop s'en soucier.

Math33
04/09/2012, 21h52
Oui comme tu dis ça fait un peu effet de palliatif mais limiter les pics de charge c'est aussi s'éviter de devoir mobiliser trop de ressources pour des serveurs de prod, le but de la virtualisation étant la consolidation, c'est pas mal de faire le maximum pour que tout aille dans ce sens ;-)

Et puis c'est très Green IT de parler optimisation !

Dès que j'ai un peu de temps j'essaie de bencher le microcache sur des petites prods qui souffrent un peu en soirée, j'essaierai de mettre quelques chiffres dessus.

nkahn
04/09/2012, 21h31
Concernant PHP-FPM, c'est devenu le standard avec Nginx mais concrètement, qu'apporte-t-il de particulier ?
J'ai l'impression que la vraie différence se fait sur l'empreinte CPU/Mémoire à performances égales. Le couple nginx/php-fpm semble en effet beaucoup moins gourmand qu'Apache avec mod_php et du coup gère mieux les montées en charge.
En tout cas c'est ma compréhension en l'état, je t'en dirai plus dès que j'aurai plus de recul.

Arrives-tu à mettre un chiffre sur la différence HTTP/HTTPS sur la même prod ?
Sur ce point, j'ai un peu été induit en erreur par ApacheBench qui a du mal à générer beaucoup de requêtes HTTPS. Je pensais que cela venait du serveur mais il s'agissait plutôt de l'outil de benchmarking (d'ailleurs je suis passé à "siege" depuis et je dois tester "tsung").
En fait, les informations sur le net indique que désormais le surcoût de l'utilisation de HTTPS est quasiment nul (voir notamment cet article de Google sur le sujet : le service Gmail a été configuré pour utiliser HTTPS par défaut avec un surcoût quasi nul).

Enfin niveau BDD, l'as-tu bien mise sur le même host de manière à optimiser les échanges ?
Oui, cela est fait et j'ai configuré le service DRS de façon a toujours garder les deux VMs sur le même hôte.
Par contre je n'ai pas encore testé le lien via une connexion "Local PortGroup", j'essayerai de faire cela plus tard (le temps de traitement moyen de mon applicatif n'est pas problématique pour le moment).

Merci en tout cas pour ces liens, je sens que je vais potasser la chose
De rien
Personnellement je vois cela comme un moyen de gérer temporairement un gros pic de charge.

Math33
03/09/2012, 10h21
J'étais en effet curieux de tweaker le cache de nginx mais par manque de temps je ne m'étais pas encore penché sur la question et là je dois dire que le concept de microcache semble très prometteur !

Comme le dit si bien l'auteur dans l'article, avec un Wordpress un peu chargé on tombe vite très bas au niveau des benchs et des performances globales du serveur.
Cependant, j'imagine que le microcache fausse un peu les benchmarks dans la mesure où il simule un chargement simultané massif d'une même page qui est donc bien mise en cache pendant un instant très court. A ce petit jeu, forcément nginx est une fusée mais à voir dans un environnement de production d'un ou plusieurs sites/forums...

Concernant PHP-FPM, c'est devenu le standard avec Nginx mais concrètement, qu'apporte-t-il de particulier ?

Pour le SSL, nginx n'est en effet pas spécialement véloce, cela dit Apache non plus. A ce niveau malheureusement il n'y a pas réellement de solution à y apporter. Arrives-tu à mettre un chiffre sur la différence HTTP/HTTPS sur la même prod ?

Enfin niveau BDD, l'as-tu bien mise sur le même host de manière à optimiser les échanges ? A voir si en + cela ne vaut pas le coup de faire communiquer les VMs par le vlan interne (si ce n'est pas déjà fait).

Merci en tout cas pour ces liens, je sens que je vais potasser la chose

nkahn
02/09/2012, 21h52
Finalement je suis parti sur la solution 1 VM "Web" (Nginx/PHP-FPM/APC) + 1 VM "BDD" (MySQL).
La VM "Web" nécessite beaucoup de ressources, je lui ai donc alloué 8 vCPUs (le maximum avec vSphere 4.1).
La VM "BDD" est moins sollicitée, je reste donc à 1 vCPU pour le moment.

Sans surprise, mes tests montrent que les facteurs limitant sont :
- l'utilisation de SSL (cela demande plus de ressources CPU à nginx)
- l'utilisation de la BDD (les pages PHP sont plus lentes en raison des temps de connexion à la BDD)
Bref, un refactoring est tout aussi nécessaire que l'optimisation des paramètres de Nginx et PHP-FPM.

Par contre, pour alléger la VM "Web", j'ai introduit une VM "Reverse Proxy" avec une gestion de "micro-cache" comme expliqué dans les articles suivants :
- MICROCACHING: SPEED YOUR APP UP 250X WITH NO NEW CODE
- Hosting Grails web applications using Tomcat and Nginx
L'approche est vraiment intéressante et élégante je trouve et cela apporte un vrai plus à charge élevée (attention de bien gérer les règles de cache pour les utilisateurs qui s'authentifient).

nkahn
29/08/2012, 21h32
En règle général la CPU des VMs "Web" (PHP-FPM) est assez élevée.
J'ai joué sur les paramètres pour éviter le respawning des process php-FPM mais la consommation CPU reste toujours élevée.

-Nicolas

Math33
29/08/2012, 20h39
Dans le cas d'un benchmark, le thin provisionning n'apportera pas de différence vu qu'il ne sollicite le stockage qu'en lecture.

De mon côté je préfère mettre nginx en reverse proxy frontal et apache en prefork derrière pour traiter les requêtes php. Attention de bien régler APC aussi pour que le cache ne sature pas trop vite.

Lorsque tu lances le benchmark, comment le CPU se comporte. Est-il saturé ?

nkahn
29/08/2012, 18h29
Merci de votre retour.

Je planifie actuellement mon architecture pour supporter une charge élevée même si celle-ci se manifestera probablement par pics.

Mon test de référence se fait via ApacheBench depuis un serveur dédié fourni par un autre hébergeur.
Code:
ab -c 100 -t 120 https://mondomain/monsite
Pour le moment, la modification du nombre de vCPU affectée à chaque VM ne semble pas avoir un impact important sur les performances car les résultats restent globalement les mêmes (je passe de 86 req/s à 96 req/s en allouant 2 vCPUs au lieu d'une à chaque VM, sachant en plus que l'utilisation de plus d'une vCPU sur une VM m'empêche d'utiliser l'option "Fault Tolerance").

J'attend le retour d'OVH pour tester un autre type de stockage disposant d'un cache en lecture en plus du cache en écriture.
Mes VMs ont été créées avec le mode "thin provisioning", je vais voir si je peux changer cette option sinon il faudra que je clone les VMs existantes.

Au niveau logiciel, j'ai testé plusieurs configurations au niveau Nginx et PHP-FPM sans grand succès pour le moment.

-Nicolas

Math33
29/08/2012, 16h28
Bonjour,

Il n'y a pas de meilleure solution "passe-partout", tout dépend des besoins auxquels doit répondre l'architecture que tu montes.
T'embêter à monter 3 ou 4 VMs avec du frontal, load balancing etc pour un trafic faible n'a pas grand intérêt.

L'avantage de la virtualisation est néanmoins de respecter la règle 1 service = 1 serveur sans pour autant verser dans le gaspillage de ressources (merci l'overcommitment ^^).
Envisage ta 1ère solution si tu ne prévois pas de monter en charge, la 2ème si en revanche tu envisages d'avoir une certaine montée en charge et un besoin de flexibilité au niveau des serveurs web.

Côté performances pures, la virtualisation est un petit peu en retrait mais tu peux limiter l'écart de performances en plusieurs axes :
- gérer les affinités des VMs pour que les VMs Web et SQL se trouvent sur le même host (histoire que le trafic inter-VM soit direct et n'utilise pas le réseau)
- taper un peu + dans le cache et optimiser aussi bien la partie web (optimisation APC) que la partie SQL (optimisation MySQL)
- surveiller la conso CPU et ajuster les vCPU aux besoins (éventuellement ajuster les prios pour augmenter le sharing des VMs si tes hosts sont très chargés niveau CPU)
- surveiller les IOs disque et prioriser les VMs de prod par rapport aux VMs de dev
- éviter de trop faire de vMotion
- ne pas conserver les snapshots (car fait baisser les perfs)
- créer tes disques virtuels en zeroed thick provisionning (meilleures performances en écriture que le thin provisionning)

Si malgré ces quelques axes de recherche les performances ne sont pas satisfaisantes, essaie d'identifier un éventuel goulot d'étranglement au niveau de l'infra (via l'interface vScope fournie par OVH par ex).

Bon courage =)

nkahn
29/08/2012, 16h02
Bonjour,

Je découvre depuis quelques jours la solution Private Cloud d'OVH.
Je cherche à mettre en place une architecture Web assez classique : Nginx + PHP-FPM + APC + MySQL

J'ai testé plusieurs configurations de VM mais je n'arrive pas à trouver de solution optimale pour maximiser les performances de cette architecture.

Je cherche donc à savoir quelles sont les meilleures pratiques de mise en place de serveur Web dans le cadre d'un datacentre virtuel.
- 2 VM avec plusieurs vCPU : 1 VM "Web" (Nginx/PHP-FPM/APC) + 1 VM "BDD" (MySQL)
- plusieurs VMs pour le Web : 1 VM "load balancer/reverse proxy" (Nginx) + N VMs "Web" (PHP-FPM/APC) + 1 VM "BDD" (MySQL)

Pour le moment, toutes les configurations testées ont des performances très en dessous de celle d'un serveur dédié classique (CPU 4x2x2.53GHz et 8Gb RAM).

Merci d'avance pour votre aide et vos conseils.

-Nicolas