L’optimisation de la programmation Web

· Niveau : INTERMÉDIAIRE
· Compatibilité : Tous les navigateurs

Il y a quelques années à peine, le défi consistait à retourner, dans des temps raisonnables, l’information récupérée sur de grandes sources de données. Bien que cette notion soit encore des plus actuelles, une nouvelle variante c’est depuis ajoutée. Il est maintenant question d’une grande quantité d’utilisateurs, parfois même supérieures aux données. Cette nouvelle perspective amène un nouveau défi et de nouvelles questions qui ont sensiblement le même but, celui d’optimiser au maximum l’accès à l’information.

NOTE : Avant même de mettre un système informatique sur le Web vous devez l’optimiser au maximum. Vos bases de donnée devront respecter plusieurs règles. Pour en savoir plus sur le sujet, je vous invite à lire :

La réalité d’un serveur Web et le partage des ressources

Sur un serveur Web, les ressources sont partagées, le premier arrivé sera le premier servi et ainsi de suite. L’exécution de code dit " round-robin " partage les ressources entre les utilisateurs. Ce partage structuré permet à certains processus déterminés d’être entièrement terminés avant de passer aux autres les ressources du serveur. Il est donc très important de bien occuper les ressources afin de les libérer le plus rapidement possible. Il n’est pas rare de voir une page Web qui abuse des ressources du serveur.

Il existe plusieurs façons de bien partager les ressources du serveur. En premier lieu, assurez-vous d’utiliser le résultat de chaque ligne de code sans attendre et de ne pas remettre le résultat d’un processus à plus tard. Quelques lignes de code suffisent à retarder considérablement un serveur quand on multiplie le tout par le nombre d’applications et le nombre de visiteurs.

L’exemple suivant montre l’ouverture de 3 bases de données. Le premier exemple démontre que les trois bases sont ouvertes pendant qu’une seule est réellement utilisée.

Exemple à ne pas faire:
   Ouverture de la base 1
   Ouverture de la base 2
   Ouverture de la base 3

     Processus de la base 1
     …
     Processus de la base 2
     …
     Processus de la base 3
     …

   Fermeture de la base 1
   Fermeture de la base 2
   Fermeture de la base 3

Exemple optimisé:
   Ouverture de la base 1
    Processus de la base 1
   Fermeture de la base 1
   …
   Ouverture de la base 2
    Processus de la base 2
   Fermeture de la base 2
   …
   Ouverture de la base 3
    Processus de la base 3
   Fermeture de la base 3

L’utilisation des ressources sur un serveur alloue un certain temps pour faire votre transaction. Le " Timeout " oblige à exécuter, dans un délai raisonnable, vos processus. Une fois ce temps utilisé, le processus est tout simplement stoppé, ce qui arrive à l’occasion.. Le partage permet donc de libérer les ressources mais aussi de pouvoir bénéficier de plus d’un délai.

NOTE : La grande majorité des sites Internet se retrouvent sur un serveur qui héberge aussi des centaines d’autres sites. Tous ces sites utilisent les mêmes ressources. C’est un vrai problème dans la mesure où vous n’avez aucun contrôle sur les autres sites. Nous parlions de partage, et bien, imaginez que vous partagiez avec un avare! Si vous laissez la chance aux autres de monopoliser les ressources, l’optimisation de votre site risque de provoquer l’effet inverse.

La rapidité des processus

La mémoire et les données globales
Partager vos ressources implique de bien structurer votre code mais quoi de mieux que d’utiliser des processus rapides. Vous savez tous que la mémoire est généralement plus rapide alors pourquoi ne pas la mettre à profit. En premier lieu, vous pouvez identifier des processus stables qui ne changent que très rarement comme par exemple un menu déroulant qui contient toujours les mêmes données d’une base. Des données globales à l’ensemble d’un site peuvent être stockées en mémoire et accessibles à tous selon le serveur et le langage. Le passage de paramètres dans une requête ou l’utilisation des variables Application en ASP par exemple.

NOTE : Pour les programmeurs ASP sur serveur IIS3 et IIS4, il est absolument déconseillé d’utiliser les variables sessions. Non seulement les ressources sont très mal utilisées mais elles le sont encore même si l’utilisateur n’est plus là!

La mémoire et les fonctions
Ici la tâche devient beaucoup plus laborieuse. Il faut beaucoup lire sur le langage que vous utilisez et généralement ce n’est pas documenté. Par exemple, certaines fonctions sont plus lentes que d’autres. Parfois une fonction maison est plus rapide que celle qui vient avec le langage de programmation. En règle générale, il faut établir une grille de performances pour chaque fonction et processus. Ensuite, en jumelant des processus, vous pourrez considérer avec jugement l’options la plus rapide. De plus il faut considérer tous les langages selon leurs capacités plus ou moins performantes.

Exemples :

La recherche dans un long texte ASCII peut-être 10 fois plus longue que dans un texte en binaire même si vous devez convertir votre texte.
Stoker le résultat d’une requête SQL dans un tableau (array) pour ensuite manipuler et afficher le tableau est de loin plus rapide qu’un " recordset ".
Le Javascript interprété par le navigateur ne demande aucune ressource au serveur.
Les expressions régulières (particulièrement en Javascript) sont très rapides.
Il n’y a rien comme le Perl pour analyser un texte.
La programmation orientée-objet ou les feuilles de style (CSS) permettent l’optimisation et la simplification de vos codes mais aussi des pages moins lourdes.
L’utilisation ou non d’une procédure récursive est aussi à examiner.
Chaque langage a ses secrets. Mais le résultat est toujours le même, un code optimisé est plus complexe. Un code qui n’est pas optimisé est souvent la solution la plus simple.

La redondance
Petit rappel sur cette notion de base. Même si l’utilisation de procédures et de fonctions n’a pas un impact très marqué sur le temps d’exécution ou sur le partage des ressources, elle permet d’alléger votre code et permet donc une lecture plus rapide du code. L’utilisation des procédures et des pages en " cache ", que nous verrons dans la deuxième partie, est par ailleurs conseillée.

Conclusion
En terminant, ces notions de base s’appliquent plus ou moins selon votre serveur. La meilleure façon d’optimiser votre code restera toujours de faire et de refaire des tests. Plusieurs logiciels de " stress " permettent de simuler l’utilisation à grande échelle et de déterminer l’impact des différents processus sur le serveur. L’expérience et la sagesse empirique du programmeur n’ont pas de limite. Un bon programmeur ne cessera jamais d’optimiser son code.

En terminant, j’aimerais remercier Charles Carroll qui a répondu à plusieurs de mes questions sur le sujet.