WRInaute passionné
Voilà bien longtemps que je n'avais pas publié d'article sur l'administration serveur sur WRI. Vu le nombre de MP que je reçois pour des demandes d'aide dans le domaine de l'optimisation de serveur web, je vous livre aujourd'hui des solutions "avancées" en complément de l'article déjà publié https://www.webrankinfo.com/forum/t/article-optimiser-son-serveur-dedie.51449/.
Posons d'abord le problème : Comment puis-je, avec un serveur LAMP donné, servir plus d'utilisateurs ?
Ceux qui ont lu les articles précédents, ont compris que la limite au nombre de connections simultanées sur un serveur web était donnée par la mémoire du dit serveur. Si on ne peut pas ou on ne souhaite pas augmenter la mémoire du serveur, il faut donc diminuer la taille mémoire requise par un processus apache.
Mais comment faire ? C'est assez simple, il suffit de virer les modules apache inutiles. Que ce soit apache 1 ou 2, seul 3 modules sont nécessaires (et encore!). Il s'agit de mod_dir, mod_mime_et mod_log_config.
Maintenant, listez les modules dont vous avez réellement besoin (mod_rewrite si vous utilisez le rewriting , mod_php si vous utilisez PHP etc)
Maintenant vous pouvez recompiler apache. Voici le résultat d'une commande "ps aux" sur le même serveur avec dans le premier cas une installation d'apache universelle (faite avec apt-get) et dans le deuxième cas, une configuration maison d'apache compilée à partir des sources.
Vous remarquez que le gain mémoire est énorme pour chaque processus apache (colonne RSS). La taille mémoire nécessaire à un processus apache est divisée par 4 , on peut donc multiplier par 4 le nombre de processus apache à mémoire donnée. (Attention, le gain peut varier d'une configuration à l'autre)
Maintenant, on peut aller encore plus loin en se posant la question suivante ? Ai je besoin d'un processus de 7Mo pour servir un fichier gif de 3ko ? Bien sur que non. Voyons ce que donne une commande "ps aux" avec un serveur apache compilé sans PHP :
Un processus apache ne nécessite plus que 1,6Mo de mémoire ! Oui, mais j'ai absolument besoin de PHP.
Pas de problème, nous allons compiler un apache avec PHP que nous ferons écouter sur le port 8080 et un apache sans PHP mais avec mod_proxy que nous ferons écouter sur le port 80 et qui renverra les demande pour des fichiers PHP vers le port 8080.
En supposant que notre serveur ai 1 Go de mem consacrée à apache, nous pouvons:
dans le cas 1 (apache satndard) lancer 35 processus apache (1 Go/30Mo)
dans le cas 2 (apache compilé avec php) lancer 133 processus apache (1 Go/7,5Mo)
dans le cas 3 (2 instances d'apache) lancer 100 apache avec PHP (750Mo/7,5 Mo) plus 156 apache léger (250Mo/1,6Mo) soit 256 processus apache.
Les valeurs données ici sont des exemples mais je peux certifier que les gains sont énormes. J'utilise personnellement ce type de config sur plusieurs serveurs kimsufi débian qui fonctionnent aussi bien avec leur 256 Mo que mes anciens serveurs avec 512 ou 1 Go de mem. Si en plus vous mettez en place un système de cache pour soulager encore plus le serveurs apache PHP vous pouvez augmenter la part de mémoire dédiée au serveur apache léger et gagner encore plus de processus.
Voilà. Je dispose d'un petit tuto sur le sujet mais vu sa taille (plusieurs pages) il n'avait pas sa place sur ce forum. Mais, bientôt, je le publierais sur mon blog... quand il existera! :wink:
Posons d'abord le problème : Comment puis-je, avec un serveur LAMP donné, servir plus d'utilisateurs ?
Ceux qui ont lu les articles précédents, ont compris que la limite au nombre de connections simultanées sur un serveur web était donnée par la mémoire du dit serveur. Si on ne peut pas ou on ne souhaite pas augmenter la mémoire du serveur, il faut donc diminuer la taille mémoire requise par un processus apache.
Mais comment faire ? C'est assez simple, il suffit de virer les modules apache inutiles. Que ce soit apache 1 ou 2, seul 3 modules sont nécessaires (et encore!). Il s'agit de mod_dir, mod_mime_et mod_log_config.
Maintenant, listez les modules dont vous avez réellement besoin (mod_rewrite si vous utilisez le rewriting , mod_php si vous utilisez PHP etc)
Maintenant vous pouvez recompiler apache. Voici le résultat d'une commande "ps aux" sur le même serveur avec dans le premier cas une installation d'apache universelle (faite avec apt-get) et dans le deuxième cas, une configuration maison d'apache compilée à partir des sources.
Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
rapache 12830 0.0 2.9 129836 30204 ? S 04:02 0:00 /usr/sbin/httpd
apache 12831 0.0 2.9 128872 29332 ? S 04:02 0:00 /usr/sbin/httpd
apache 12832 0.0 2.8 128796 29232 ? S 04:02 0:00 /usr/sbin/httpd
apache 12833 0.0 2.8 128840 29228 ? S 04:02 0:00 /usr/sbin/httpd
apache 12834 0.0 1.9 119512 19656 ? S 04:02 0:00 /usr/sbin/httpd
apache 12835 0.0 2.8 128840 29240 ? S 04:02 0:00 /usr/sbin/httpd
apache 12843 0.0 2.9 128876 29280 ? S 04:02 0:00 /usr/sbin/httpd
apache 12844 0.0 1.9 119504 19616 ? S 04:02 0:00 /usr/sbin/httpd
Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
rwww-php 10598 0.0 2.9 13800 7308 ? S Jan31 2:57 /usr/local/apachephp/bin/httpd
www-php 21702 0.0 2.9 13848 7360 ? S Jan31 3:00 /usr/local/apachephp/bin/httpd
www-php 13560 0.0 2.9 13816 7368 ? S Jan31 2:51 /usr/local/apachephp/bin/httpd
www-php 4642 0.0 2.9 13680 7188 ? S Jan31 3:17 /usr/local/apachephp/bin/httpd
www-php 13570 0.0 2.9 13824 7376 ? S Jan31 2:41 /usr/local/apachephp/bin/httpd
www-php 16508 0.0 2.9 13832 7332 ? S Jan31 2:46 /usr/local/apachephp/bin/httpd
www-php 24369 0.0 2.9 13744 7264 ? S Jan31 3:22 /usr/local/apachephp/bin/httpd
www-php 4578 0.0 2.9 13804 7324 ? S Jan31 3:06 /usr/local/apachephp/bin/httpdVous remarquez que le gain mémoire est énorme pour chaque processus apache (colonne RSS). La taille mémoire nécessaire à un processus apache est divisée par 4 , on peut donc multiplier par 4 le nombre de processus apache à mémoire donnée. (Attention, le gain peut varier d'une configuration à l'autre)
Maintenant, on peut aller encore plus loin en se posant la question suivante ? Ai je besoin d'un processus de 7Mo pour servir un fichier gif de 3ko ? Bien sur que non. Voyons ce que donne une commande "ps aux" avec un serveur apache compilé sans PHP :
Code:
www-lig 17824 0.0 0.6 3100 1664 ? S Feb09 0:27 /usr/local/apachelight/bin/httpd
www-lig 31027 0.0 0.7 3108 1672 ? S Feb09 0:27 /usr/local/apachelight/bin/httpd
www-lig 10266 0.0 0.6 2980 1656 ? S Feb09 0:28 /usr/local/apachelight/bin/httpd
www-lig 7379 0.0 0.6 2972 1652 ? S Feb09 0:27 /usr/local/apachelight/bin/httpd
www-lig 9737 0.0 0.7 3116 1680 ? S Feb09 0:28 /usr/local/apachelight/bin/httpd
www-lig 11443 0.0 0.7 3108 1672 ? S Feb09 0:27 /usr/local/apachelight/bin/httpd
www-lig 31106 0.0 0.7 3112 1680 ? S Feb09 0:26 /usr/local/apachelight/bin/httpdUn processus apache ne nécessite plus que 1,6Mo de mémoire ! Oui, mais j'ai absolument besoin de PHP.
Pas de problème, nous allons compiler un apache avec PHP que nous ferons écouter sur le port 8080 et un apache sans PHP mais avec mod_proxy que nous ferons écouter sur le port 80 et qui renverra les demande pour des fichiers PHP vers le port 8080.
En supposant que notre serveur ai 1 Go de mem consacrée à apache, nous pouvons:
dans le cas 1 (apache satndard) lancer 35 processus apache (1 Go/30Mo)
dans le cas 2 (apache compilé avec php) lancer 133 processus apache (1 Go/7,5Mo)
dans le cas 3 (2 instances d'apache) lancer 100 apache avec PHP (750Mo/7,5 Mo) plus 156 apache léger (250Mo/1,6Mo) soit 256 processus apache.
Les valeurs données ici sont des exemples mais je peux certifier que les gains sont énormes. J'utilise personnellement ce type de config sur plusieurs serveurs kimsufi débian qui fonctionnent aussi bien avec leur 256 Mo que mes anciens serveurs avec 512 ou 1 Go de mem. Si en plus vous mettez en place un système de cache pour soulager encore plus le serveurs apache PHP vous pouvez augmenter la part de mémoire dédiée au serveur apache léger et gagner encore plus de processus.
Voilà. Je dispose d'un petit tuto sur le sujet mais vu sa taille (plusieurs pages) il n'avait pas sa place sur ce forum. Mais, bientôt, je le publierais sur mon blog... quand il existera! :wink:
