Préchargement des modules et compilation

Lorsque mod_perl démarre, il doit charger les modules utilisés par vos scripts :

...

use strict;

use DBI();

use CGI;

...

Dans le fonctionnement normal de Perl, les modules sont compilés lors de leur appel par les scripts -- Perl vérifie qu’ils ne contiennent pas d’erreur et les met dans un format exécutable. Ce processus est plus rapide s’il est effectué au démarrage, notamment dans le cas du gros module CGI. Pour cela, on utilise la commande compile :

...

use strict;

use DBI();

use CGI; CGI->compile(<tags>);

...

Remplacez <tags> par la liste des fonctions CGI que vous utilisez.

Persistance de l’interface avec les bases de données

Si vous utilisez une base de données, vos scripts ouvriront et fermeront en permanence des descripteurs pour effectuer les accès. Ce processus vous fait perdre du temps et peut être amélioré en utilisant Apache::DBI.

KeepAlives et MaxClients

Sur les sites chargés, cela vaut le coup de désactiver KeepAlive (voir le chapitre 3) car cette directive maintient la connexion entre le serveur et chaque client pendant un certain temps, même s’ils ne font rien. Cela consomme des processus qui, à leur tour, consomment de la mémoire : comme chaque connexion correspond à un processus et que chaque processus a sa propre instance de Perl, le code compilé et les variables persistantes en cache, sa consommation mémoire peut être très importante -- bien plus qu’avec une utilisation classique d’Apache. De même, on peut ajuster MaxClients pour éviter le swapping et ainsi améliorer les performances ; même si, paradoxalement, cela force les clients à attendre.

Utilisation d’un profiler

L’outil classique pour accélérer les programmes s’appelle un profiler. Cet outil compte les cycles d’horloge de chaque ligne de code exécutées par le processeur : le compte total de chaque ligne montre alors le temps qu’elle a pris au cours de l’exécution du programme. Le résultat est un fichier log, qui peut être trié par un autre programme afin de mettre en évidence les lignes qui consomment le plus de temps. Très souvent, vous ne pourrez pas faire grand chose pour corriger les problèmes qui sont ainsi mis en évidence : il faut bien exécuter les instructions, et cela prend du temps, c’est tout. Cependant, en certaines occasions, le profiler vous montrera que le problème est dû à une fonction qui est appelée plus souvent qu’elle ne le devrait : vous pouvez alors la sortir de la boucle ou réorganiser cette boucle pour qu’elle fonctionne plus efficacement afin que votre script en tire profit.

Il existe un profiler pour Perl, DProf, disponible sur CPAN (voir http://search.cpan.org ). Il y a deux façons de l’utiliser (voir la documentation), la meilleure étant de placer la ligne suivante dans votre fichier de configuration :

...

PerlModule Apache::DProf

...

Cette ligne active le profiler et crée un répertoire dprof/$$ situé sous <ServerRoot>. Dans celui-ci, vous trouverez un fichier nommé tmon.out contenant les résultats que vous pourrez étudier en utilisant le script dprofpp fourni avec le paquetage.

Aussi intéressants que soient les résultats d’un profiler, ils ne méritent pas qu’on y passe trop de temps. Si une partie du code prend 50% du temps d’exécution (ce qui est assez improbable), s’en débarrasser ne fera que doubler la vitesse d’exécution ; si une partie du code prend 10% du temps d’exécution (ce qui est beaucoup plus probable), s’en débarrasser (en supposant que c’est possible) ne fera gagner que 10% en vitesse d’exécution, ce que personne ne remarquera.