Si les temps de calcul d'un élément de la page sont importants et que l'élément change peu, il est intéressant de le sauvegarder tel quel pour le restituer rapidement et soulager le processeur.

Par exemple, dans le cas de statistiques simples (nombre d'utilisateurs inscrits, etc.), il peut être intéressant de stocker les statistiques en cache. Dans le cas de graphiques complexes, il peut être intéressant de stocker l'image, générée par le code PHP, pour une durée déterminée plutôt que de ré-effectuer les calculs pour chaque utilisateur.

Memcache est un système de cache pour stocker les éléments qui concernent la session des utilisateurs, des résultats de requêtes etc. Il permet d'éviter d'utiliser des ressources du serveur afin qu'il réponde plus rapidement. Performant, il peut stocker n'importe quel objet PHP sérialisable, et peut être partagé entre plusieurs serveurs dans le cas d'une architecture avec load-balancing.

Vous pouvez utiliser Memcache pour stocker des résultats de requêtes SQL coûteuses, des statistiques, etc.

Tout comme Memcache, APC (pour Alternative PHP Cache) est un système de cache, mais à la différence de Memcache, APC est capable de mettre en cache les « opcodes ». Quand un script PHP est exécuté, il est d'abord compilé en interne par PHP. PHP ne stocke pas le résultat compilé du script et donc, à la prochaine exécution du script, PHP le recompilera.

APC est conçu pour stocker le résultat compilé dans son cache. Ainsi, lorsque PHP exécute le script, APC lui servira directement le script compilé. PHP n'aura pas besoin de recompiler le script et économisera donc beaucoup de temps.

La simple installation d'APC peut diviser la charge des processus Apache/PHP par 2 ou 3. N'hésitez donc pas à l'utiliser !

Vous pouvez également utiliser APC comme un cache classique, mais à la différence de Memcache, APC ne fonctionne que sur un serveur.

Dans des environnements complexes, les deux existeront côte à côte : APC pour mettre en cache les opcodes, et Memcache pour mettre en cache les calculs / requêtes.

SYMPTÔMES : le nombre de connexions simultanées en pic est très important. Les processus Apache saturent, certains clients ne reçoivent pas les pages web quand le trafic est élevé.

Apache permet de configurer le nombre de connexions simultanées qu'il peut ouvrir (c'est-à-dire le nombre de requêtes client auxquelles il peut répondre simultanément).

Dans la plupart des installations, vous utiliserez les modules Worker ou Prefork. Les installations LAMP classiques utilisent par défaut le module Prefork, mais il faut savoir que d'autres solutions existent. De réputation, Prefork serait plus stable et Worker plus scalable. Quoi qu'il en soit, chaque module MPM (Multi-Processing Modules), que ce soit Prefork ou Worker, utilise des paramètres qu'il convient d'examiner car ils ne conviennent pas forcément à des sites ayant une forte fréquentation. Ces paramètres peuvent brider votre application.

BON À SAVOIR : dans le journal Apache, vous verrez facilement si le MaxClients est atteint.

NOTE : il existe des alternatives au serveur web Apache. La plus connue est LightHTTPD. Ce serveur web est réputé plus performant. Mais avant de considérer cette option, sachez que la communauté travaillant sous Apache est bien plus vaste, et que les gains en performance ne sont pas toujours sensibles.

SYMPTÔMES : vos ressources RAM et CPU peuvent être consommées par l'applicatif (PHP) en temps de calcul, ou par la base de données. Dans le cas où vous avez diagnostiqué qu'il s'agit d'une surconsommation de ces ressources par le processus Apache (https), il sera nécessaire de passer en revue le code de l'application et sa configuration.

PHP, comme JAVA ou la plupart des langages de programmation récents gère automatiquement la libération des ressources qui ne sont plus utilisées (gérée par le garbage collector). Néanmoins, les FileHandler et les ResultSet doivent impérativement être fermés de façon explicite, car ils ne sont pas pris en compte par le garbage collector.

Ainsi, si votre application effectue des lectures/écritures sur des fichiers, n'oubliez pas que chaque pointeur de fichier créé doit être fermé :

$fh = fopen($filename, 'r');
while(!feof($fh)){
    //...
}
fclose($fh);

D'autre part, si vous n'utilisez pas de framework ORM qui gère lui-même la récupération des données, veillez à fermer les ResultSets qui ont été ouverts :

$rSet = mysql_query("SELECT * FROM users");
while ($user = mysql_fetch_object($rSet)){
    //...
}
mysql_freeresult($rSet);

SYMPTÔMES : la consommation processeur de vos processus PHP est trop élevée.

Cette fonctionnalité permet de trouver une classe si elle n'a pas été identifiée dans le contexte courant. Ainsi, votre code PHP peut charger les classes PHP dont il a besoin « à la volée ». Par exemple, l'objet $user, de la classe User, ne peut être instancié si le fichier User.class.php n'a pas été inclus (« require_once »).

Exemple :

/* Définir une manière de trouver la classe User */
function custom_autoload($className){
    require_once 
    dirname(__FILE__) . "/classes/" .$className . ".class.php";
}
 
/*
 * Ajouter la fonction custom_autoload à la liste
 * des fonctions permettant de trouver une classe.
 */
spl_autoload_register('custom_autoload');
 
/* Sans autoload, cette instanciation aurait généré une Erreur:
 * Fatal error: Class 'User' not found in ...
 */
$user = new User();

Cet exemple semble trivial, mais imaginez que vous disposez d'une librairie de classes que vous utilisez partout dans votre application. Par défaut, deux options sont envisagées :

• inclure « à la volée » les classes que vous utilisez à chaque fois, ce qui devient vite fastidieux ;
• faire l'inclusion de tous les fichiers au début du script, mais vous incluez alors des fichiers qui ne sont pas utilisés dans tous les scripts, d'où une consommation inutile de RAM et de temps processeur.

Utiliser l'autoload est donc fortement recommandé, et cette solution est même plus efficace que celle qui consiste à inclure les fichiers à la volée, car un « require_once » doit vérifier si ce fichier a été déjà inclus ou non.

La conception la plus intuitive et la plus simple d'un projet est souvent pensée en synchrone. Néanmoins, la mise en place de processus asynchrones permet à la fois de diminuer le temps d'attente de l'utilisateur, et de lisser les pics de charge.

Pensez notamment à externaliser les tâches suivantes :

• production de rapport, mise à jour de statistiques ;
• envois de mails ;
• appels de services externes.

L'Ajax (Asynchronous JavaScript And XML) est une manière de dialoguer avec le serveur après le chargement de la page, grâce au JavaScript. L'intérêt est de charger les éléments qui prennent du temps après que le navigateur de l'utilisateur a affiché le contenu de la page internet.

Si vous avez un calcul long, que vous devez faire à chaque fois et que malgré toutes les recommandations que vous avez suivies, vous ne pouvez pas réduire le temps, alors il est préférable d'afficher la page sans cet élément puis de récupérer le résultat sur le serveur ensuite.

Toutefois, il faut faire attention car certains moteurs de recherche ne pourront pas indexer le contenu de ce bloc.

NOTE : ATTENTION AUX FRAMEWORKS. Certains frameworks et certains CMS doivent charger un ensemble de modules et d'outils avant de passer à l'exécution du code « effectif ». Dans la mesure du possible, lorsque vous faites de l'Ajax, essayez de charger le moins d'éléments possible pour limiter la durée d'exécution et ainsi accélérer le retour d'information.
NOTE : requêtes multiples. Si une page effectue plusieurs appels Ajax, sachez que PHP ne pourra traiter la requête suivante qu'une fois que la session aura été libérée (fonction session_write_close). En effet, la session étant par défaut libérée en fin d'exécution du script, les requêtes Ajax pourront alors être traitées simultanément.