Je recherche à optimiser en terme de performances (utilisation ressources et rapidité des réponses http)
Il s’avère qu’après différents tests la meilleur performance est obtenue
en splitant de moitié le système des caches.
Méthode utilisée :
Dans le fichier ecrire/public cacher.php
dans la fonction : function public_cacher_dist
ajout des lignes :
$use_cache = -1;
$chemin_cache = “”;
$lastmodified = 0;
$page = array();
return;
après if ($chemin_cache) return creer_cache($page, $chemin_cache, $use_cache);
SPIP génère donc les caches des squelettes sous leur forme php.
Malheureusement les caches html des pages ralentit l’affichage des page et accroît la charge sur le serveur.
Connaissez vous une méthode plus efficace que celle décrite ci-dessus ?
Ne faudrait il pas repenser completement la gestion des caches ?
Pourquoi faire appel à la base de donnée ?
Il est tout a fait possible de gérer les fichiers (date, suppression, etc) sans faire appell à celle-ci.
Il est possible de surcharger public_cacher pour effectuer l’optimisation suivante :
Dans le fichier mes_fonctions.php
function public_cacher {
if ($chemin_cache) return creer_cache($page, $chemin_cache, $use_cache);
// Les pages ne sont plus mises en cache sur le serveur
// #CACHE{} permet la mise en cache par le navigateur des pages.
// Seul les squelettes sont mis en cache sur le serveur dans le dossier CACHE/skel/
// La table spip_caches n’est plus modifiée
$use_cache = -1;
$chemin_cache = “”;
$lastmodified = 0;
$page = array();
return;
Il est possible de surcharger public_cacher pour effectuer l'optimisation
suivante :
Sur quelles bases estimes-tu qu'il s'agit d'une optimisation ? Quand
tu as 100 visites par minute sur le site, le cache des pages est
indispensable.
Ce que tu fais ne revient-il pas tout simplement à indiquer $delais=0; partout ?
// La table spip_caches n'est plus modifiée
C'est peut-être les requêtes sur cette table qui devraient être
optimisées ? Il faut voir qu'avec le nouveau système d'invalidation
cette table a beacoup moins d'importance qu'avant ; si elle ralentit
le système on pourrait sans doute la bazarder.
Je considère qu’il s’agit d’une optimisation au vu des test que j’ai pu effectuer (j’avoue que mes procédures de test sont loin d’être exemplaire).
La méthode précedemment donnée accélère considérablement l’affichage des pages.
Je suis d’accord avec toi sur le faite que pour 100 requête par minutes il devrait être possible de mettre un système de cache performant.
J’y travaille en me basant sur la librairies cache_lite de PEAR. Dès que ceci sera fait je l’ajouterais en tant que contirb.
Je considère qu'il s'agit d'une optimisation au vu des test que j'ai pu effectuer (j'avoue que mes procédures de test sont loin d'être exemplaire).
C'est une optimisation pour ton usage qui doit faire appel à des squelettes relativement simples.
Pour une utilisation plus complexe, ne pas mettre les fichiers en cache dégraderait largement les perfs.
Un squelette relativement simple peut rapidement faire 30 ou 40 requetes, comparé à la requete sur spip_caches... c'est pas comparable !
C'est à toi de trouver le bon equilibre.
Perso, je me permet des choses tres complexes dans des squelettes mis à jour une fois par semaine (le cache serait illimité, ca m'irait aussi) et à coté de ca, j'ai des caches à 10secondes, juste pour eviter les recalculs inutiles si l'utilisateur s'enerve sur sa touche F5...
Je suis par principe opposé au cache à 0, car dans ce cas, je pense qu'il faut preferer du PHP dans les squelettes (directement ou via des balises), qu'on pourra largement optimiser avec un PHPAccelerator.
La bonne approche pour ameliorer le cache, amha, c'est plutot l'invalidation.
Une fois qu'on pourra invalider simplement du cache, on pourra se passer du temps de mise en cache et donc de la table des caches (le cache existe, on l'utilise, il a été detruit par l'invalidation, on le regenere).
