(fourni par )

L'anti-PEAR
Bien que j'aime PEAR, je ne peux pas l'utiliser dans tous les projets, et je n'ai pas l'intention de l'installer pour utiliser simplement les mécanismes de cache. Étant donné que j'ajoute le cache sur un site Web qui présente des symptômes de ralentissement, je préfère disposer d'une bibliothèque personnalisée de mon cru.

Le concept du cache est très simple. Un cache est un mécanisme capable d'intercepter le résultat d'une action particulière et de le sauver dans un endroit particulier, accessible rapidement. Les prochaines requêtes du même type seront alors traitées avec ce cache, et non pas recalculées. Le contenu ainsi sauvé est remis à jour suivant un calendrier précis, ou bien après certains événements.

La plupart des gens pensent qu'un cache doit être rafraîchi à une fréquence prédéfinie, mais ce n'est pas nécessaire le cas. Par exemple, si vous mettez en cache des données basées sur un fichier, vous pouvez simplement vérifier que le fichier n'a pas été modifié depuis la mise en cache. Lorsque la date de modification d'un fichier dépasse celle du cache, il est temps de faire le rafraîchissement. Mieux encore, vous pouvez combiner les deux techniques : vous ne vérifiez la date de modification du fichier qu'une fois de temps en temps. Vous allez encore réduire la charge sur le disque.

L'une des questions primordiales du cache est de savoir où placer les données. Comme les mécanismes de cache sont généralement ajoutés pour des questions de vitesse, il faut trouver le medium de stockage le plus rapide possible. La mémoire vive est définitivement le système le plus rapide, et c'est là que l'extension SHMOP entre en scène : c'est une des extensions de mémoire partagée de PHP.

Malheureusement, la mémoire est aussi une ressource très limitée, et SHMOP n'est pas disponible sur Windows, à moins de ne faire fonctionner PHP qu'en module dans le serveur Web (Apache ou IIS). Par conséquent, nous avons besoin d'un mécanisme de sauvegarde sur le disque, qui sera déclenché dans 2 circonstances : soit nous utilisons Windows, soit la conservation de la mémoire est primordiale.

Je suis certain que les mots de "fichiers sur le disque" vous sont venus à l'esprit immédiatement : ce n'est pas rare, et ce n'est pas non plus une mauvaise idée. Accéder à un fichier sur un disque peut sembler être une proposition coûteuse, en termes de performances, mais si votre système d'exploitation est optimisé, il va automatiquement compenser ce coût. On peut ramener le problème à cette constatation : si le script qui a besoin du cache est exécuté très fréquemment, alors l'OS va probablement mettre le fichier dans son cache mémoire, et accélérer encore la vitesse de lecture. Sinon, l'impact du chargement du fichier sur le disque sera minimal, comparé au temps d'exécution du script, et vous y gagnerez de toute manière.

Je sais que je simplifie un peu le problème ici, car j'omets différents facteurs, tels que l'indépendance du serveur avec le mécanisme de cache, ou du nombre de scripts utilisé par votre application. N'oubliez pas que je présente ici le cache comme une solution rapide à vos problèmes d'optimisation, et que vous aurez toujours à optimiser vos scripts. Si vous êtes amenés à utiliser des systèmes de cache un peu partout sur votre site web, alors votre problème est global, et vous devez étudier systématiquement votre application pour trouver le goulot d'étranglement, avant de risquer un peu plus la stabilité de votre serveur.

Prenons un exemple : supposez que votre site Web lise des bannières dans une source externe, et que, pour une raison quelconque liée au fonctionnement de la régie publicitaire, vous devez lire ces publicités au moment de la génération de la page, au lieu de simplement utiliser un petit morceau de JavaScript. C'est une situation dans laquelle votre application ne dépend pas de vos erreurs ou de votre cache : c'est la régie de publicité qui est lente. Il faut peut-être améliorer la connectivité entre les serveurs de la régie et les vôtres.

Par conséquent, comme vous ne pouvez pas modifier le code de la régie afin de l'accélérer, vous décidez de mettre en place un système de cache, et votre première question est : où donc placer le contenu du cache ? Si vous avez quelques bannières pour tout votre site, vous pourriez simplement mettre cela en mémoire vive. D'un autre côté, si vous avez un groupe de bannières pour chaque page, vous pourriez consommer rapidement toute votre mémoire, et en priver les autres processus qui en ont besoin, comme les processus du serveur Web.

Forum

Réagissez dans les forums de JDN Développeurs

Même si vous travaillez sur une plate-forme Unix, il n'est pas inutile d'avoir une bibliothèque de cache qui fonctionne à la fois en mémoire et sur le disque. De cette manière, vous pouvez utiliser la RAM pour les pages les plus fréquemment sollicitées, et les fichiers pour celles qui sont moins souvent réclamées.