WRInaute passionné
Tout les webmasters ont été un jour confronté au problème suivant : "mon site est maintenant à l'étroit sur son hébergement actuel, quelle solution choisir ?"
On débute sur un mutualisé, puis on passe sur un petit dédié, puis un dédié plus gros et puis ...
Cet article à pour objectif de proposer des solutions d'évolutions d'architectures serveur en tenant compte des performances et des coûts.
En matière de terminologie, pour la clarté de l'article, j'appellerais "serveur" la machine physique (l'ordinateur) et "service" le logiciel (l'application). Je prendrais également pour hypothèse que le serveur est un serveur LAMP (linux + apache + mysql + php)
Avant de choisir une architecture "serveur" il faut avant tout définir les "services" dont on a besoin, les principaux étant, dans le cas qui nous intéresse, le "service web", le "service mail", le "service ftp", le "service base de données".
Je ne parlerais pas du "service ssh", indispensable pour se connecter sur son "serveur" à distance, ni des "services" de type système.
Nous avons donc notre "serveur" qui héberge ces "services" et nous sommes à l'étroit en raison du la charge (en gros du trafic) et nous n'avons pas les moyens de prendre un serveur plus gros et plus cher ! que faire ?
1 ère solution, l'optimisation
Si le serveur est un serveur clé en main, les différents "services" installés sont configurés de façon disons, universelle, pour répondre aux besoins du plus grand nombre. Il est donc intéressant de regarder, "service" par "service" aec quelles options ils sont installés et compilés afin de supprimer ce qui ne sert pas.
Pour le "service" web, si c'est apache, reportez vous à mes articles optimiser son dédié et bien configurer apache
Pour le "service" base de données, si c'est mysql, un petit coup d'oeil à l'excellente doc en ligne de mysqlvous permettra de "tuner" efficacement votre "service" mysql pour grappiller quelques ressources.
En ce qui concerne le "service ftp", posez-vous la question de son utilité (hé oui! j'ai connu bien des cas ou il ne servait à rien !) même si votre site propose aux utilisateurs d'uploader des fichier, il existe des alternatives à ftp.
Pour le service mail, on distingue le "smtp" et le "pop" (ou l'imap). Si votre serveur doit envoyer des mails (contact, newsletters) le smtp est nécessaire. Par contre, posez-vous la question de l'utilité du pop, vous pouvez trés bien héberger vous boites aux ailleurs à moindre coût.
Enfin pour PHP, vous pouvez bien entendu optimiser votre code, installer un cache d'opcode etc ... Mais le résultat le plus spectaculaire sera obtenu en recompilant PHP aprés avoir supprimer l'inutile ! J'en voie qui froncent les sourcils d'un air dubitatif. Je m'explique par l'exemple:
Utilisez-vous les fonctions wddx_xxxxxxx ? Non, alors vous n'avez pas besoin de la librairie WDDX.
Utilisez-vous les fonctions mhash_xxxxxx ? Non, alors vous n'avez pas besoin de la librairie HASH.
Utilisez-vous les fonctions ftp_xxxxxx ? Non, alors vous n'avez pas besoin de la librairie FTP.
etc ....
Une fois identifiées les librairies inutiles (là, il faut regarder la doc PHP) il vous suffit de recompiler PHP en désactivant le support des dites librairies (par exemple --disable-ftp --disable-wddx etc ...)
Le gain en occupation mémoire des processus apache-php est considérable (j'ai diminué de 60% cette taille de processus sur certaines config!)
2 éme solution, 2 serveurs valent mieux qu'un (à coût constant)
je vais prendre un exemple rapide que j'ai expérimenté (je tiens avant tout à préciser que les hébergeurs cités le sont à titre d'exemple et la qualité de leurs services respectifs n'est en aucun cas débatus dans cet article)
2 dédibox (processeur C7 2 Ghz, 160 Go disque et 1 Go de mem) se sont avérés plus performant qu'un superplan 2007 + (à 'époque Core2duo 2x1,8 Ghz , 2 Go de mem et 160 Go de disque) pour un coût inférieur de 30 %. Le gain de charge était voisin de 50 %.
Dans ce cas précis, l'architecture était la suivante:
Serveur 1 : Apache + PHP (serveur de pages web)
Serveur 2 : Mysql + lighttpd(serveur mysql et serveur d'image).
Les raisons ? Tout d'abord, apache est un gros consommateur de processus donc de mémoire. Mysql est lui un gros consommateur de CPU, et de mémoire. La solution de les installer sur des machines différente est bien connue et a fait ses preuves.
La petite innovation de la solution étant de faire tourner un serveur d'image sur la même machine que mysql. Le choix du service web s'étant porté sur lighttpd en raison de sa faible trace mémoire et de ses meilleures performances q'apache pour servir des fichiers "statiques". D'autres parts, notre apache du serveur 1, ainsi délivré de la charge de servir des images avec des processus surdimensionnés pour cela s'en trouvait bien mieux.
Enfin, les deux serveurs se backupaient l'un l'autre (avec une tache cron rsync en ssh) , histoire d'utiliser l'espace disque libre.
Actuellement, je travaille à la mise en place d'une architecture identique à deux serveurs avec en plus un service de streaming vidéos (avec conversion automatique des formats vidéos)
Pour conclure, si malgré tout vous êtes à l'étroit, il reste encore la solution de la répartition de charge multiserveurs (load-balancing) mais une telle architecture sort du cadre de cet article et de ce forum. :wink:
[ j'édite ce post pour apporter une précision suite à un MP: ]
En ce qui concerne PHP, certains modules sont compilés par défaut. Si ils sont innutiles il faut les désactiver à la compilation. Ensuite, si PHP est installé par apt-get (debian) ou yum (fedora) ou autre, il n'y a qu'a regarder avec phpconfig() pour voir l'ensemble des modules compilés avec php et trés souvant il y en a beaucoup d'inutiles.
On débute sur un mutualisé, puis on passe sur un petit dédié, puis un dédié plus gros et puis ...
Cet article à pour objectif de proposer des solutions d'évolutions d'architectures serveur en tenant compte des performances et des coûts.
En matière de terminologie, pour la clarté de l'article, j'appellerais "serveur" la machine physique (l'ordinateur) et "service" le logiciel (l'application). Je prendrais également pour hypothèse que le serveur est un serveur LAMP (linux + apache + mysql + php)
Avant de choisir une architecture "serveur" il faut avant tout définir les "services" dont on a besoin, les principaux étant, dans le cas qui nous intéresse, le "service web", le "service mail", le "service ftp", le "service base de données".
Je ne parlerais pas du "service ssh", indispensable pour se connecter sur son "serveur" à distance, ni des "services" de type système.
Nous avons donc notre "serveur" qui héberge ces "services" et nous sommes à l'étroit en raison du la charge (en gros du trafic) et nous n'avons pas les moyens de prendre un serveur plus gros et plus cher ! que faire ?
1 ère solution, l'optimisation
Si le serveur est un serveur clé en main, les différents "services" installés sont configurés de façon disons, universelle, pour répondre aux besoins du plus grand nombre. Il est donc intéressant de regarder, "service" par "service" aec quelles options ils sont installés et compilés afin de supprimer ce qui ne sert pas.
Pour le "service" web, si c'est apache, reportez vous à mes articles optimiser son dédié et bien configurer apache
Pour le "service" base de données, si c'est mysql, un petit coup d'oeil à l'excellente doc en ligne de mysqlvous permettra de "tuner" efficacement votre "service" mysql pour grappiller quelques ressources.
En ce qui concerne le "service ftp", posez-vous la question de son utilité (hé oui! j'ai connu bien des cas ou il ne servait à rien !) même si votre site propose aux utilisateurs d'uploader des fichier, il existe des alternatives à ftp.
Pour le service mail, on distingue le "smtp" et le "pop" (ou l'imap). Si votre serveur doit envoyer des mails (contact, newsletters) le smtp est nécessaire. Par contre, posez-vous la question de l'utilité du pop, vous pouvez trés bien héberger vous boites aux ailleurs à moindre coût.
Enfin pour PHP, vous pouvez bien entendu optimiser votre code, installer un cache d'opcode etc ... Mais le résultat le plus spectaculaire sera obtenu en recompilant PHP aprés avoir supprimer l'inutile ! J'en voie qui froncent les sourcils d'un air dubitatif. Je m'explique par l'exemple:
Utilisez-vous les fonctions wddx_xxxxxxx ? Non, alors vous n'avez pas besoin de la librairie WDDX.
Utilisez-vous les fonctions mhash_xxxxxx ? Non, alors vous n'avez pas besoin de la librairie HASH.
Utilisez-vous les fonctions ftp_xxxxxx ? Non, alors vous n'avez pas besoin de la librairie FTP.
etc ....
Une fois identifiées les librairies inutiles (là, il faut regarder la doc PHP) il vous suffit de recompiler PHP en désactivant le support des dites librairies (par exemple --disable-ftp --disable-wddx etc ...)
Le gain en occupation mémoire des processus apache-php est considérable (j'ai diminué de 60% cette taille de processus sur certaines config!)
2 éme solution, 2 serveurs valent mieux qu'un (à coût constant)
je vais prendre un exemple rapide que j'ai expérimenté (je tiens avant tout à préciser que les hébergeurs cités le sont à titre d'exemple et la qualité de leurs services respectifs n'est en aucun cas débatus dans cet article)
2 dédibox (processeur C7 2 Ghz, 160 Go disque et 1 Go de mem) se sont avérés plus performant qu'un superplan 2007 + (à 'époque Core2duo 2x1,8 Ghz , 2 Go de mem et 160 Go de disque) pour un coût inférieur de 30 %. Le gain de charge était voisin de 50 %.
Dans ce cas précis, l'architecture était la suivante:
Serveur 1 : Apache + PHP (serveur de pages web)
Serveur 2 : Mysql + lighttpd(serveur mysql et serveur d'image).
Les raisons ? Tout d'abord, apache est un gros consommateur de processus donc de mémoire. Mysql est lui un gros consommateur de CPU, et de mémoire. La solution de les installer sur des machines différente est bien connue et a fait ses preuves.
La petite innovation de la solution étant de faire tourner un serveur d'image sur la même machine que mysql. Le choix du service web s'étant porté sur lighttpd en raison de sa faible trace mémoire et de ses meilleures performances q'apache pour servir des fichiers "statiques". D'autres parts, notre apache du serveur 1, ainsi délivré de la charge de servir des images avec des processus surdimensionnés pour cela s'en trouvait bien mieux.
Enfin, les deux serveurs se backupaient l'un l'autre (avec une tache cron rsync en ssh) , histoire d'utiliser l'espace disque libre.
Actuellement, je travaille à la mise en place d'une architecture identique à deux serveurs avec en plus un service de streaming vidéos (avec conversion automatique des formats vidéos)
Pour conclure, si malgré tout vous êtes à l'étroit, il reste encore la solution de la répartition de charge multiserveurs (load-balancing) mais une telle architecture sort du cadre de cet article et de ce forum. :wink:
[ j'édite ce post pour apporter une précision suite à un MP: ]
En ce qui concerne PHP, certains modules sont compilés par défaut. Si ils sont innutiles il faut les désactiver à la compilation. Ensuite, si PHP est installé par apt-get (debian) ou yum (fedora) ou autre, il n'y a qu'a regarder avec phpconfig() pour voir l'ensemble des modules compilés avec php et trés souvant il y en a beaucoup d'inutiles.