Serveur dédié

Les joies de l'optimisation des performances d'un serveur dédié

Il y a de nombreuses possibilités d'optimisation côté serveur. Nous ne parlerons ici que de produits disponibles pour Apache / php.

Opcode

A chaque page, le serveur exécute une série de tâches (interprétation et compilation du code) gourmandes en temps d'exécution. L'idée ici est de ne le faire qu'une fois en conservant le résultat dans un cache. Il y a beaucoup de produits, chacun ayant ses particularités : eaccelarator, APC, Zend Platform: en http://www.zend.com/en/products/platform/.

Une fois installés, ces produits tournent tous seuls et gèrent eux même leur cache.

Mise en cache de variables

A chaque page il y a des informations recalculées, par exemple un menu. Plutôt que de faire et refaire des traitements qui donnent toujours le même résultat et donc consomment des ressources inutiles, on va placer en cache le résultat lors du premier calcul. On accède ainsi plus rapidement au résultat tout en libérant des ressources.

Soit le faire pour chaque utilisateur à l'ouverture de sa session, soit globalement pour tout le monde. Le plus simple est de commencer par mette en cache les menus, header, footer, ainsi que quelques éléments gourmands qui ne changent pas à chaque affichage. On peut donc stocker simplement le résultat d'une requête SQL, un calcul, un bout de page...

Pour que cela fonctionne il faudra modifier le code applicatif. C'est relativement simple. Voici un petit exemple pour APC, pour stocker et récupérer la variable $bar :

apc_add('foo', $bar),

 

Pour récupérer la donnée :

$bar = apc_fetch('foo')

 

On peut utiliser memcached, ou APC (oui, il gère aussi le cache mémoire) ou tout autre produit.

Bien entendu il faudra coder la gestion de ces variables, cela à donc un cout en développement. D'autre part il faut également surveiller la mémoire disponible. D'un autre côté, les gains de performances peuvent être énormes. A vous donc de décider si le jeu en vaut la chandelle.

Utiliser un ramdisk

Les fichiers temporaires sont stockés sur disques durs. La RAM étant plus rapide, l'idée est d'y stocker ces fichiers. Il faut être prudent, et bien calculer l'espace mémoire disponible. Il faut éviter de saturer la RAM, sous peine de dégrader les résultats, ou pire encore : planter le serveur. Il faut également penser qu'en cas de reboot du serveur, c'est fichiers disparaissent purement et simplement.

Une fois le répertoire monté, on pourra y placer les fichiers générés par eaccelarator par exemple. On peut aller plus loin en écrivant un script qui au démarrage va placer en mémoire d'autres éléments : scripts, .JS, .CSS...

Il existe plusieurs méthodes pour ce faire, j'en retiens ici une relativement simple sous linux, implémentée depuis le noyau 2.6 : tmpfs (Temporary File System). TmpFS gère la quantité de mémoire allouée, et utilise également le swap en cas de débordement. Evitez de trop charger la mule, le swap limitant fortement les performances. Précédemment vous pouviez également utiliser ramfs, sans toutefois avoir la possibilité des limites mémoire et le swapping.

Solution de stockage

Les accès disques sont une cause de ralentissement possible. Les accès disque sont omniprésents : charger et délivrer des fichiers, accéder à la base de donnée, fichiers temporaires... Plus les disques sont lents, plus l'application le sera. Pour accélérer les accès, il n'y a qu'une voie : changer le hardware !

Plusieurs pistes s'ouvrent à vous : disques plus rapides si les vôtres sont vraiment anciens, utilisation de disques montés en RAID, disques SSD. Ou un mélange.

Le système RAID permet de répartir les informations sur plusieurs disques. Soit pour obtenir un gain en terme de performance (striping), soit pour accroitre la sécurité (disques miroirs). On peut également obtenir les 2 avantages.

Un disque SSD est un disque dur constitué de mémoire flash. N'ayant aucune pièce mécanique, ce type de stockage est donc plus rapide qu'un disque classique et les données ne disparaissent pas au reboot comme sur un ramdisk. Par contre la durée de vie d'un SSD est inférieure à celle d'un disque classique. Certains sont annoncé pour durer le million d'heures, cela laisse quand le temps de voir venir. On peut bien sur monter un SSD en RAID.

Optimiser un serveur : A voir également

La mise en cache SQL, qui ne peut se faire que sur un dédié, est dans un chapitre à part.

Sur des infrastructures à très fort trafic, il existe des systèmes dit de load balancing. Cela signifie que les utilisateurs sont répartis sur différents serveurs en fonction de la charge, à la manière d'une gare de triage.

Sources / Pour aller plus loin

Ressource Serveur dédié

A propos de l'auteur

Jacques Terrier

Jacques Terrier AKA Cobolian : Premier site en 98, puis quelques belles références à son palmarès. Fort de son background technique et marketing, Jacques est consultant e-commerce.