[article] Optimiser son serveur dédié

[fandecine]

Voila bien longtemps que j'avais ce post en préparation, mais par manque de temps, je ne l'avais pas publié. N'étant pas un accros des cérémonies commémoratives , je profite de cette journée du 8 mais pour vous le présenter.

Il s'adresse à tous les webmaster qui souhaitent tirer un meilleur profit de leur serveur LAMP.

PRÉAMBULE

L'optimisation universelle d'un serveur LAMP n'existant pas, cet article a pour objectif de vous donner les éléments que vous adapterez à vos besoins.

Avant toute modification de configuration de votre serveur, il est nécessaire de réfléchir aux moyens de mesurer les changements de performances induits et mettre en place un banc de test.

Pour mesurer l'impact de vos modifications je vous en propose 2 outils:

apache bench (ab) normalement présent sur votre serveur apache. C'est un utilitaire en ligne de commande qui, même si il ne reproduit pas une utilisation de votre serveur par de vrais internautes, vous permettra de faire des comparaisons au grés des modifications de configuration.

syntaxe: a -n100 -c10 http://domaine.com/page.html

Dans cet exemple on effectue 100 requêtes par groupe de 10 (en parallèle) sur la page du domaine ou serveur domaine.com/page.html


httperf téléchargeable à l'adresse http://www.hpl.hp.com/research/linux/httperf/

Bien entendu, on effectuera les tests depuis une machine différente de la machine à tester pour ne pas fausser les mesures.

En complément de ces outils, on pourra utiliser un script php pour mesurer le temps de génération de la page testée:

Code: Tout sélectionner

// au debut du script
function tjs_GetTempsTraitement($timer1) {
  $timer2 = microtime();
  $timer2 = substr($timer2,strpos($timer2," ")) + substr($timer2,0,strpos($timer2," "));
  $timer1 = substr($timer1,strpos($timer1," ")) + substr($timer1,0,strpos($timer1," "));
  return round( ($timer2-$timer1) * 10000)/10;
}
$ChronoStart = microtime();

//en fin de script
$temps = tjs_GetTempsTraitement($ChronoStart);
$temps=$temps/1000;
echo"Page générée en ".$temps." seconde";
if ($temps>=2) echo "s";


Un accès au gestionnaire server-status permettra de prendre un instantané des processus apache activés ainsi que de la mémoire occupé qui nous servira pour affiner certains réglages.

Avant de commencer:

Personnellement, je monte moi-même mes serveurs à partir de la distribution linux (généralement une fedora 4) et je n'installe que le strict nécessaire sur le serveur y compris en ce qui concerne les modules apache. Le gain de performance n'est pas significatif mais cela me permet de choisir les versions d'application installée et évite une grande partie des trous de sécurité. La compréhension de ce topic nécessite un certaine connaissance des serveurs LAMP.


Les Optimisations d'apache:

note: nous allons modifier notre configuration apache à partir du fichier httpd.conf. Après chaque modif, il faut re-démarrer apache. Certaines modifications peuvent êtres testées sans modifier la configuration apache en utilisant la fonction PHP

Désactiver les logs d'accès Apache

Les logs d'accès apache génèrent une multitude d'accès disque et sont d'autant plus "bavards" que votre site dispose d'une audience importante. Le fichier acces.log peut ainsi contenir des millions de lignes et occuper plusieurs gigas sur votre serveur. Lorsque c'est le cas, lors de la rotation des logs, votre serveur peut devenir inaccessible aux visiteurs. D'autre part, ce type de fichier devient de part sa taille inexploitable donc inutile.

Pour désactiver les logs d'accès apache, dans le fichier httpd.conf:

CustomLog /dev/null combined

La directive HostnameLookups

Cette directive permet si apache effectue une requête de recherche des DNS ou pas. Il faut savoir qu'une recherche DNS peut être très longue et dépend du temps de réponse de l'adresse cliente et non de votre serveur. D'autres part, si l'adresse cliente ne peut être examinée, il faudra à la requête DNS une minute avant d'abandonner, temps pendant lequel le processus chargé de cette recherche ne pourra servir à rien d'autre. Il faut donc vérifier que cette directive est à Off (sur apache 2, c'est la valeur par défaut alors que sur apache 1.3 la valeur par défaut est On)

La directive AllowOverride

Cette directive indique à apache si il doit chercher un fichier .htaccess dans chacun des répertoires du chemin menant au fichier demandé. Vous comprenez évidemment l'implication sur les performances d'apache.

Si vous n'utilisez pas les fichiers .htaccess, mettez cette directive à none pour tous les répertoire de votre serveur.

Si vous utilisez les fichiers .htaccess, mettez cette directive à none pour tous les répertoire de votre serveur puis utilisez les section <Directory> pour n'activer les fichiers .htaccess uniquement ou cela est nécessaire.


Voila pour ce qui est d'apache. Les utilisateurs plus avertis pourront se pencher sur les directives MaxClients
La directive MaxClients, KeepAlive et les directives de MPM prefork et MPM workers.

Du coté de PHP

En dehors de la qualité du code, il existe des solutions pour améliorer les performances de PHP:

La configuration de php (php.ini) contient de nombreuses valeurs par défaut qu'il est intéressant de modifier pour augmenter les performances de PHP. Et puis, J'ai l'habitude de désactiver tout ce qui est inutile:

expose_php: Par défaut, chaque requête PHP émet un entête HTTP appelé X-Powered-By ce qui est une perte de temps et qui est totalement inutile (sauf pour les personnes qui cherchent à pénétrer sur votre système en se basant sur votre configuration ). Donc je met expose_php = Off

magic_quotes_gpc: La solution de facilité consiste à mettre magic_quotes_gpc On. Grave erreur! Cela impose de nombreuse vérifications à PHP sur les variables en entrée des script (et sur un site dynamique il y en a beaucoup!) et la plupart du temps c'est inutile car la grande majorité de ces variables ne conduisent pas à un trou de sécurité. De plus, le webmaster pense être protégé des attaques par injection de code ce qui est malheureusement insuffisant. Je préfère gérer moi-même la protection de mes scripts (fonction addslashes() par exemple ou mysql_escape_string() pour les requêtes MySQL) j'économise des ressources, du temps d'exécution et le code de mes scripts est indépendant de la configuration du serveur. Donc, magic_quotes_gpc = Off

output_buffering: Par défaut, PHP envoyer les données au navigateur en mesure que le script les lui transmet ce qui implique de nombreuses opération d'écriture/envoi et ralentit l'exécution du processus en invoquant de nombreux appels système. L'idéal et de fixer la taille du buffer de sorties à la valeur moyenne de la taille des pages de votre site pour essayer d'envoyer le contenu en une seule fois. Veiller cependant à ne pas mettre une valeur trop grande car une exécution simultanée de nombreux processus PHP risquerait de saturer votre mémoire!

register_argc_argv: Utile seulement pour exécuter PHP en mode ligne de commande. Donc, dans le cas d'un serveur web register_argc_argv = Off.

register_globals: Beaucoup de webmasters activent cette directive par habitude et facilité car ils n'on jamais ré-écrit leurs scripts depuis les versions avant PHP 4.2.0. C'est tellement facile de récupérer directement les arguments passés au script par leur nom de variable. Mais outre la faille de sécurité que cela représente, cela oblige PHP à stocker un nombre de variables très souvent inutiles. Donc, register_globals=Off. En plus, je met variables_order = GPC et j'utilise get_env() pour accéder aux variables systèmes et aux variables d'environnement. Tout cela réduit le temps d'analyse des variables en entrée de script et économise de la mémoire. (Pour ceux qui ont du mal suivre, lisez attentivement la doc PHP consacrée aux super globales)

mysql_allow_persistent: Pour un serveur mutualisé, il me parait indispensable de mettre cette directive à Off. Dans d'autres cas, il y a matière à discussion. Personnellement je la met à Off pour éviter que chaque processus Apache ait une connexion particulière à la base de données ce qui finit toujours par entraîner un "Too many connections" même sur de très grosses configurations. Je prends également soin de fermer toutes mes connexions Mysql explicitement dans mes scripts.

Indépendamment de la configuration de PHP, il existe d'autres solutions pour accélérer l'exécution de PHP:

L'utilisation d'un compilateur PHP:

Le langage PHP est un langage de script donc dit interpréter. A chaque exécution de script, le serveur doit lire le fichier, l'analyser, le vérifier, et le transformer en pseudo code avant de l'exécuter. Le processus est d'autant plus long que les scripts sont complexes et lourds. Pour éviter cela, on peut installer un compilateur. Personnellement j'utilise Zend Optimizer (utilisation gratuite sous licence Zend http://www.zend.com/products/zend_optimizer). Les gain de performance sont impressionnant sur certain site (jusqu'à 10 fois plus rapide! )

La mise en cache des scripts:

Je ne vais pas refaire le débat sur l'utilisation d'un cache et quel cache utiliser ici. Référez vous au post http://www.webrankinfo.com/forums/viewtopic_28614.htm
La dernière version de cache maison que j'utilise à base de fichiers XML présente l'avantage, outre les performances, de rendre le contenu indépendant de l'habillage du site ce qui me permet de modifier une section du site très rapidement et sans effacer le cache.

Après PHP, intéressons nous à MYSQL. Je ne parlerais pas de la qualité du code (il me faudrait un site web en entier! ). Je me contenterais de donner un petit truc simple à mettre en oeuvre et diablement efficace dans mon cas.

Lors de nombreuses modifications de vos tables Mysql, celles-ci se fragmentent et perdent leur optimisation. Mysql vient à notre secours avec deux commandes (Optimize et Analyse). Comme il n'est pas question que j'exécute ces commandes manuellement, je paramètre une tache cron journalière pour faire le travail à ma place toute les nuits (lorsque même mes serveurs sommeillent! )

Les plus accros pourront paramétrer le cache de requêtes mysql. Pour ma part, les essais que j'ai effectué ont montré que le gain de performance ce faisait au détriment d'une trop grosse consommation de mémoire. Le système de mise en cache des pages ne consomme lui, aucune ressource mémoire pour un gain bien plus important au niveau des performances. Mais je me garderais de généraliser car les gains de performances dépendent trop du type de sites et/ou d'applications installées sur le serveur.

Voilà. En espérant que ce topic vous sera utile.

PS: Merci de poser vos question sur ce fil et non en MP pour en faire profiter tout le monde.

edit: juste pour corriger quelques fautes d'orthographe!

[WebRankInfo]

merci ! un bon candidat aux recommandations

[birkoss]

+1 en effet.

Par contre, apache bench a des limites dans les requetes qu'il envoie ??

Car ca peut facilement virer en DOS sur certaines machines si plusieurs s'y mettent non ?

[fandecine]

+1 en effet.

Par contre, apache bench a des limites dans les requetes qu'il envoie ??

Car ca peut facilement virer en DOS sur certaines machines si plusieurs s'y mettent non ?

C'est juste un outil de test et de mesure rudimentaire mais utile.

Pour ce qui est attaques, c'est pas le plus efficace!

[Bourriquet]

CustomLog /de/null combined

Ca serait pas plutôt ça ?
CustomLog /dev/null combined

[tjs]

Les gars qui s'approprient le travail des autres sans citer leur source me feront toujours marrer...

voir l'original ici http://www.toutjavascript.com/savoir/op ... mance.php3
et pages suivantes...

[karak]

C'est exactement les infos que j'étais en train de chercher.

Merci.

[WebRankInfo]

tjs, j'ai parcouru l'article que tu cites, je ne retrouve pas les conseils fournis par fandecine... Cela dit ne créons pas de polémique, et restons dans le sujet SVP.

[JeunZ]

Ah je suis content de voir que sans aucune connaissances mais avec deux ans d'expérience en serveur j'avais fait quelques modifs que tu indiques (couper les logs, ...).

Je vais étudier tes autres indications.

Merci et bravo.

[fandecine]

merci Bouriquet, je corrige de suite!

Les gars qui s'approprient le travail des autres sans citer leur source me feront toujours marrer...

voir l'original ici http://www.toutjavascript.com/savoir/op ... mance.php3
et pages suivantes...

Lorsque l'on est aussi vindicatif, on va au bout de ses recherches et on trouve l'origine des origines http://fr.php.net/manual/fr/function.microtime.php

Mais, pour satisfaire les grincheux, une liste de liens ayant servis, entre autre, à la rédaction de cet article:

http://www.toutjavascript.com/savoir/op ... mance.php3 (pour le script php de mesure du temp de génération d'une page), mais je pourais citer http://www.tommyweb.org/sourcesphp/tpspage.html

http://www.apachefrance.com/
http://httpd.apache.org/docs/1.3/programs/ab.html
http://www.hpl.hp.com/research/linux/httperf/
http://www.linux-france.org/article/web ... elinux.php
http://www-fr.mysql.com/
http://www.php.net/

Tant que j'y suis, pour ceux qui veulent aller plus loin, un article sur le module de compression à la volée d'apache (mod_gzip) qui permet d'économiser de la bande passante:
http://www.devparadise.com/technoweb/sys/d57.php

On peut aussi donner quelques référence bibliographiques, mais le plus simple est d'aller sur http://www.oreilly.fr/ faire son choix.

[spijoelx]

en ce qui concerne de couper les logs, il me semble qu'en france il est obligatoire d'en stocker 6mois non ?

[casa]

Merci pour ces precieux conseils

si je désactive access.log:
est ce que awstats va toujours marcher ?
et je suppose qu'il faut aussi désactiver le cron qui lance access.log ?

merci

[ajax]

C'est exactement ce que je me demandais aussi. A mon avis awstats ne marchera plus car une fois j'ai du vider mes logs et cela a affecté les stats de la journée.

[fandecine]

Merci pour ces precieux conseils

si je désactive access.log:
est ce que awstats va toujours marcher ?
et je suppose qu'il faut aussi désactiver le cron qui lance access.log ?

merci

Effectivement, en desactivant les logs d'acces, les outils de stats type awstat, webalizer etc ne fonctionne pas, mais, pour continuer dans le cadre de l'optimisation d'un serveur, je rajouterais un conseil: Externaliser tout ce qui est possible cela soulagera votre serveur d'autant. Pour les stats, il suffit de s'abonner à xiti ou estat (gratuit).

Enfin, ne pas oublier que la desactivation des logs d'accés présente un interet d'autant plus grand que les fichiers générés sont importants. Le gain pour un site à faible trafic n'est pas forcement significatif.

je suppose qu'il faut aussi désactiver le cron qui lance access.log ?

il n'est pas necessaire de modifier les jobs cron.

[casa]

Merci encore pour ces conseils et les autres scripts qui permettent de progresser


casa