TUTORIELS 
Gérer la montée en charge d'un site
Cinq conseils pour envisager une amélioration de la vitesse d'affichage, ou éviter les goulets d'étranglement entre le serveur et l'utilisateur.  (1er mars 2004)
 
Construire un site ou un service Web ne correspond qu'à une petite partie de son cycle de vie. Tout aussi importante soit-elle, elle ne peut complètement présager de l'utilisation réelle du site, et c'est pourquoi il faut s'assurer, tant lors de la conception que tout au long de sa vie, qu'il ne survient pas de goulet d'étranglement (bottleneck) entre le serveur et l'utilisateur. Nous allons ici donner quelques conseils pour envisager et améliorer la montée en charge d'un site...

1) Optimiser son code
Lors de la construction d'un site Web dynamique ou d'un service Web, l'un des premiers éléments à prendre en compte est évidemment l'optimisation de son code. Tout les développeurs d'applications "desktop" cherchent toujours à accélérer la complétion d'une requête, le développeur Web doit lui-aussi sans cesse chercher à améliorer son code, et donc, en passant, à se débarrasser de certaines habitudes prises lors de l'apprentissage de la syntaxe.

Certains langages sont en effets suffisamment simples pour permettre de réaliser beaucoup sans connaître son fonctionnement interne sur le bout des doigts, mais les développeurs "cowboys" risquent surtout de limiter l'application sur le long terme, les contraignant à souvent réécrire le code pour s'adapter à la demande. Sans devoir pour autant devenir "chirurgien" du code, un développeur digne de ce nom se doit de connaître les possibilités de son langage.

La majorité des sites dynamiques font par ailleurs appel à une base de données, qui peut se révéler elle-même être un goulet d'étranglement : les requêtes SQL, mal maitrisées, peuvent rapidement mettre à genoux un serveur sous le nombre des requêtes, ou les requêtes prenant trop de temps. SQL n'est pas un langage à sous-estimer, et connaître les vertues de SELECT peut se révéler miraculeux pour la vitesse des requêtes

A noter, dans le monde PHP, l'existence au sein de ADOdb (
une couche d'abstraction de SGBD) d'un système de "Performance Monitoring" : il surveille les requêtes SQL, et signale celles qui sont probablement mal écrites, et/ou qui mériteraient d'être améliorées.

2) Mettre à jour ou modifier le système
Si le code est optimisé autant que possible mais que le site tende toujours à perdre en performances, il ne faut plus regarder du coté du software mais du hardware. Les prix du matériel ont tellement baissé qu'il est aujourd'hui peut-être plus intéressant d'investir dans de la RAM, un disque-dur plus rapide, un nouveau serveur, un serveur de cache ou une plus grosse bande passante (ou un compresseur-accélérateur de trafic) que de chercher à reprogrammer le site.
Par ailleurs, les logiciels serveurs (Apache, IIS...) ou les SGBD sont souvent réglés pour un nombre donné de connexions, nombre qui ne correspond pas forcément aux besoins du site : il ne faut donc pas hésiter à se plonger dans leurs documentations pour en tirer la substantifique moelle.

3) Utiliser des outils de test et d'optimisation automatique
Nombreux sont les systèmes et langages qui disposent, d'origine ou par le biais de développeurs tiers, d'outils permettant de mesurer la vitesse d'exécution des requêtes données au serveur, ou pouvant améliorer grandement les performances d'un site. Pour PHP, de tels exemples sont la bibliothèque PEAR::Benchmark, PEAR::Cache et PEAR::Cache_Lite, ou bien les produits Zend Cache et Zend Optimizer.

4) Faire usage des standards du web
La charge qui se fait sur le serveur est due à deux faits : le nombre d'éléments demandés par l'utilisateur, et leurs poids. Nombreux sont les sites (même statiques) dont la lourdeur de la mise en page empêche une navigation rapide : après avoir envoyé une page HTML surchargée de balises dépassées (FONT et autres), le serveur doit envoyer parfois plusieurs dizaines d'images pour afficher une interface parfaite au sein d'un tableau.
Cela fait pourtant presque 8 ans qu'est parue la première spécification CSS, permettant non-seulement de se débarrasser des balises FONT, mais aussi des mises en page reposant sur de lourds tableaux... Là où un site "à l'ancienne" doit charger l'ensemble de ses éléments pour chaque nouvelle page, un site en CSS se repose sur un simple fichier décrivant la mise en page des informations...

Forums
* Discutez en sur les forums

5) Compresser les données
Le protocole HTTP permet d'utiliser un système de compression, ce qui peut faire gagner jusqu'à 75% de la taille d'un élément, et donc alléger d'autant la charge sur le serveur. La plupart des navigateurs modernes sont capables de décompresser des pages zippée, et la plupart des serveurs modernes disposent d'options permettant de zipper des pages (mod_zip, httpZip, PipeBoost, ...) : il serait dommage de ne pas profiter de cette méthode simple et rapide de soulager sa machine (à la condition que le besoin soit réel, tant l'acte de compression peut lui-même se révéler lourd en temps-machine...).

 
[ Xavier BorderieJDNet
 
Accueil | Haut de page