[article] Faire évoluer son architecture serveur
36 messages • Page 1 sur 3 • 1, 2, 3
Consultez la formation à Google Analytics de WebRankInfo / Ranking Metrics
[article] Faire évoluer son architecture serveur
le Dim Nov 04, 2007 15:36
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.
[ 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.
[ 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.
Dernière édition par fandecine le Dim Nov 04, 2007 19:40, édité 1 fois.
le Dim Nov 04, 2007 17:49
pour compléter , lighttpd peut aussi s'installer en local sur un dédié et vous pouvez ensuite rediriger les requetes pour un sous domaine type "images.monsite.com" sur ce serveur web avec le mod proxy d'apache.
utile si vous avez une grosse gallérie d'images et pas les moyens de vous payez un gros serveur
+1 pour la reco
utile si vous avez une grosse gallérie d'images et pas les moyens de vous payez un gros serveur
+1 pour la reco
le Dim Nov 04, 2007 19:18
Mumuri a écrit:pour compléter , lighttpd peut aussi s'installer en local sur un dédié et vous pouvez ensuite rediriger les requetes pour un sous domaine type "images.monsite.com" sur ce serveur web avec le mod proxy d'apache.
utile si vous avez une grosse gallérie d'images et pas les moyens de vous payez un gros serveur
+1 pour la reco
A ce sujet, il faudrait que je fasse des test avec apache en serveur principal et mod-proxy qui redirige sur lighttpd pour le statique et l'inverse, lighttpd en principal qui redirige vers apache pour le php, voir aussi lighttpd seul avec php tournant en cgi.
Je n'ai aucune idée à priori de la solution la plus efficace.
J'utilise déjà des config avec deux apaches (un avec php, un pour le statique) pour des serveurs ou je mutualise plusieurs clients et ça marche trés bien avec un gain de performence appréciable.
le Lun Nov 05, 2007 2:16
Auriez-vous un site référence "pour les nuls" puis un site pour approndir (ou les 2 en 1) pour apprendre à installer et gérer un serveur ?
Je désire apprendre d'ici peu à gérer moi meme mes serveurs, seulement j'aimerai un guide pour pas trop me planter (sachant que les sites seront en prod, je peux pas dire de tout planter).
On a souvent des informations intéressantes (comme ici) mais vue de l'extérieur, pas simple à mettre en pratique. Ou sinon, à l'inverse, on a des infos concrètes mais qui sont expliqués pour ceux qui connaissent déjà et là, c'est du chinois.
Je désire apprendre d'ici peu à gérer moi meme mes serveurs, seulement j'aimerai un guide pour pas trop me planter (sachant que les sites seront en prod, je peux pas dire de tout planter).
On a souvent des informations intéressantes (comme ici) mais vue de l'extérieur, pas simple à mettre en pratique. Ou sinon, à l'inverse, on a des infos concrètes mais qui sont expliqués pour ceux qui connaissent déjà et là, c'est du chinois.
le Lun Nov 05, 2007 2:58
tonguide a écrit:Auriez-vous un site référence "pour les nuls" puis un site pour approndir (ou les 2 en 1) pour apprendre à installer et gérer un serveur ?
Installation complète : -http://olange.developpez.com/articles/debian/installation-serveur-dedie/
Les commandes de base de Linux : -http://www.linux-france.org/article/debutant/debutant-linux.html
Si tu veux un conseil, installe toi une petite Knoppix en local à partir du LiveDVD (Knoppix est une debian en mode bureau assez agréable [avis perso])... Et test 2-3 commandes...
L'article de fandecine est excellent, mais bon, il aurait dû commencer par "prendre un dédié si vous connaissez un minimum Linux et son environnement"...
Le premier guide dont je t'ai donné le lien est parfait si tu prends un serveur dédié sous une Debian de base... (Juste l'install de vsftpd que je remplace par proftpd). Et te permet d'avoir un serveur parfaitement stable.
Si les sites sont en prod comme tu le dis, je te conseil aussi de prendre la box la moins cher que tu trouveras, voir un Virtuel pour t'amuser et surtout pour apprendre...
le Lun Nov 05, 2007 13:19
Ok merci pour les conseils.
Je pense effectivement que ça serait plus raisonnable de prendre un mini dédié (voir un PC chez moi ?) pour apprendre à gérer tout ça.
Je met ces 2 sites en favoris donc !
Je pense effectivement que ça serait plus raisonnable de prendre un mini dédié (voir un PC chez moi ?) pour apprendre à gérer tout ça.
Je met ces 2 sites en favoris donc !
le Lun Nov 05, 2007 18:30
Bonjour
J'ai trouvé cette série d'articles très intéressante.
J'ai un serveur dédié avec une configuration qui commence à dater:
mysql Client API version 4.0.24
PHP Version 4.3.10-22
Apache/2.0.54 (Debian GNU/Linux)
Sur ce serveur j'ai 2 vieux scripts que je souhaite garder: phpbb en version 2.03 et un vieux lifetype 1.0.3.
Bien sur ces scripts mêmes vieux ont été mis à jours contre quelques hack, mais ils gardent leur config d'origine.
Bref, mon hosteur me propose de basculer mon serveur avec les derniers mysql 5. que faut-il craindre ? existe-il une possibilité à l'installation de garder un mysql plus compatibles avec les anciens scripts ?
Merci.
J'ai trouvé cette série d'articles très intéressante.
J'ai un serveur dédié avec une configuration qui commence à dater:
mysql Client API version 4.0.24
PHP Version 4.3.10-22
Apache/2.0.54 (Debian GNU/Linux)
Sur ce serveur j'ai 2 vieux scripts que je souhaite garder: phpbb en version 2.03 et un vieux lifetype 1.0.3.
Bien sur ces scripts mêmes vieux ont été mis à jours contre quelques hack, mais ils gardent leur config d'origine.
Bref, mon hosteur me propose de basculer mon serveur avec les derniers mysql 5. que faut-il craindre ? existe-il une possibilité à l'installation de garder un mysql plus compatibles avec les anciens scripts ?
Merci.
le Lun Nov 05, 2007 21:44
poupee a écrit:Bonjour
J'ai trouvé cette série d'articles très intéressante.
J'ai un serveur dédié avec une configuration qui commence à dater:
mysql Client API version 4.0.24
PHP Version 4.3.10-22
Apache/2.0.54 (Debian GNU/Linux)
Sur ce serveur j'ai 2 vieux scripts que je souhaite garder: phpbb en version 2.03 et un vieux lifetype 1.0.3.
Bien sur ces scripts mêmes vieux ont été mis à jours contre quelques hack, mais ils gardent leur config d'origine.
Bref, mon hosteur me propose de basculer mon serveur avec les derniers mysql 5. que faut-il craindre ? existe-il une possibilité à l'installation de garder un mysql plus compatibles avec les anciens scripts ?
Merci.
UUUUUH! sur un site en production avec des scripts non développé par moi, je ne prendrais pas le risque de passer mysql de 4 à 5 sans faire de test préalable.
Pour cela, j'ai un serveur de test (un kimsufi) que je martyrise souvant (installations, re-installations, compilations etc ..). Mais cela peut se faire avec un vieux pc, mais pose toi d'abord la question "est ce bien necessaire ?". Ta config est pas si vieille que ça aprés tout.
![[article] Faire évoluer son architecture serveur](http://forum.webrankinfo.com/styles/wriv4/imageset/fr/page-suivante.png "Voir la page suivante"){kind=small}
36 messages • Page 1 sur 3 • 1, 2, 3
Formation recommandée sur ce thème :
Formation Google Analytics : en 2 jours, apprenez comment exploiter l'essentiel des possibilités de l'outil de mesure d'audience de Google. Formation animée par Julien Coquet, expert certifié officiellement par Google Analytics.
Tous les détails sur le site Ranking Metrics : programme, prix, dates et lieux, inscription en ligne.
Lectures recommandées sur ce thème :
- Stratégies financières sur l'évolution de l'architecture Google
- L'infrastructure technique de Google (Juillet 2006)
- Comment créer une page web en PHP
- Article sur le fichier .htaccess
- Explications sur le Crawl Caching Proxy de Google
- Yahoo déclare-t-il la guerre aux référenceurs ?
- Gestion des langues et des sessions en PHP / MySQL
- Changements de nom de domaine et TrustRank
- Changer d'hébergeur web sans pénaliser son référencement
- La Google Dance : description...
- [article] Sécuriser son serveur LAMP
- [article] Optimiser son serveur dédié
- [Article] Lighttpd et apache sur le même serveur II
- [article] Optimiser son serveur dedié part II
- Article sur la sécurisation d'un site web (et du serveur)
- faire un lien vers un article dans un flux RSS
- Qui veut faire un article sur VOD/DVD pour RadioFrance.fr ?
- [article] Comment faire des liens en dur dans son annuaire
- Url Rewriting article par article
- article-nom-article.html.php VS article-12-5.php
- Changement de serveur: que faire?
- Faire ue image de son serveur
- un serveur dédié, comment faire, que choisir?
- Faire communiquer 2 serveur entre eux
- Faire passer le serveur pour qqn...
Consultez la description détaillée des produits ou services de Google suivants : Google Web Accelerator
- La classe C de l'adresse IP
Cet outil vous permet de vérifier si plusieurs sites sont hébergés sur la même classe C (adresse IP du serveur). - Test du code HTTP d'une page
Cet outil vous permet de connaître le code HTTP renvoyé par le serveur pour une page donnée.
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités
- Index du forum
- L’équipe du forum • Supprimer les cookies du forum • Heures au format UTC + 1 heure
- Flux RSS de WebRankInfo :
le forum- les articles des dossiers
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
, traduction par phpBB-fr.com, mod SEO par phpbb-seo.com
Contact
Confidentialité