|
|
|
|
TUTORIEL PHP |
|
|
|
Optimiser vos applications PHP |
La popularité grandissante du Web met une pression croissante sur les logiciels et le matériel utilisé pour les applications. Cet article va vous donner les tuyaux pour réduire la charge de vos serveurs, et augmenter la capacité de vos applications sans avoir à vous ruiner en mises à jour matérielles.
(30/03/2004) |
|
(fourni
par )
Configurer
correctement PHP
Maintenant que nous avons choisi nos options générales de compilation,
passons en revue la configuration de PHP lui-même car certaines
options ont un impact significatif sur les performances.
Dans la plupart des cas, PHP est utilisé pour servir des pages
web, et le plus souvent comme module Apache. L'approche standard
est de compiler PHP comme un module partagé que le serveur charge
au démarrage. C'est la meilleure méthode, car elle permet de
faire des mises à jour faciles de PHP, sans avoir à recompiler
Apache en entier. Toutefois, cette méthode ne donne pas les
meilleures performances.
Lorsque vous générez un module dynamique, le compilateur va
ajouter une série d'interfaces pour permettre au module d'être
chargé. De plus, le compilateur ne peut pas optimiser le code
au maximum. Le résultat est une version de PHP qui est entre
10 et 25% plus lente que si PHP est compilé statiquement dans
Apache.
# Configuration de PHP
./configure --with-apache=/path/to/apache_source
# Configuraiton d'Apache
./configure --activate-module=src/modules/php4/libphp4.a
La procédure ci-dessus va compiler PHP directement dans Apache,
en faisant de PHP une partie d'Apache. Comme vous pouvez alors
l'imaginer, les prochaines mises à jours d'Apache ou de PHP
requièrent la recompilation des deux applications. Cependant,
étant donné la faible fréquence des nouvelles versions de ces
logiciels, le supplément de compilation nécessaire compense
largement le gain de performances.
Vous pouvez combattre l'augmentation du temps de compilation
en réduisant le nombre d'extensions que PHP intègre : cela va
aussi améliorer vos performances. Par défaut, PHP compile un
grand nombre d'extensions que vous risquez de ne jamais utiliser.
En bout de course, cela ne fera qu'accroître la taille de votre
PHP, et la mémoire qu'il réclame. Pire : certaines extensions
vont initialiser différents buffers et paramètres à chaque requête
HTTP, et ralentiront le processus de génération. Essayez autant
que possible d'identifier les extensions que vous utilisez,
et désactivez celles que vous n'utilisez pas.
./configure \
--disable-all \
--disable-cgi \
--disable-cli \
--with-apache=/path/to/apache_source \
--enable-session \
--with-pcre-regex \
--with-pgsql \
L'exemple ci-dessus utilise l'indicateur de configuration -disable-all,
pour désactiver toutes les extensions actives par défaut, et
cela d'un seul coup, ce qui vous permet d'économiser le temps
nécessaire à la recherche des extensions par défaut et à leur
désactivation. Il va aussi automatiquement désactiver toutes
les extensions nouvellement activées par défaut, s'il en apparaît
par la suite sans qu'elles soient spécifiées manuellement dans
la configuration. Les directives de configuration -disable-cgi
et -disable-cli désactivent
la génération des versions CLI et CGI dont la compilation n'est
pas automatiquement désactivée par le marqueur
-disable-all. Puisque seul le SAPI Apache est nécessaire,
il est inutile de perdre du temps à construire des binaires
qui ne seront pas utilisés.
Une fois les extensions et SAPIs inutiles désactivés, les extensions
nécessaires activées, la compilation peut commencer. Le résultat
final est un binaire plus compact, qui est spécialement important
pour des SAPIs comme CGI et CLI où le coût de démarrage se paie
à chaque demande. Un binaire plus petit se chargera bien plus
vite, ce qui lui permet de démarrer le traitement du code plus
rapidement. De plus, il est important de noter que les initialisations
non nécessaires ne seront pas faites, ce qui permet à PHP de
travailler plus vite dans tous les cas, quelque soit le SAPI
sous-jacent.
|
|
|
|
|
|