HERETIQUE TU ES ... HERETIQUE TU RESTES !
Ben oui, comme d'habitude, il faut que je me fasse les trucs à ma sauce :!: J'ai lu l'enorme topic épinglé sur le sujet ... ainsi que les multiples variantes et alternatives proposées sur des sites linkés par ce topic ... Interessant mais usant ... vu la taille du topic ...
Ce que j'en retiens est que la mise en cache de page entière ne me convient pas :
1 - Ca implique que seule la version visiteur non inscrits/connecté est "cachable" et que donc seuls les visiteurs non inscrits sont concernés (tant sur le plan vitesse pour eux que sur le plan décharge de la bdd par eux). Les membres inscrits eux auront un affichage plus lent et se traduiront par une charge supérieure ... Pas glop pas glop ...
2 - Qu'il vous vienne à l'idée d'ajouter une "*" sur un élément présent sur toutes les les pages (style un onglet de plus dans la barre de menu ou même n'importe quel element statiques dans les pages) et hop c'est tout votre cache (ou toutes le spages ayant en commun cet élément statique) qui devient obsolète et part à la benne ... et devra être regénéré (soit massivement soit petit a petit au gré des affichages de page).
3 - Il est des contextes (mutu) ou la place sur disque est aussi comptée et donc mettre l integralité de la page en cache revient a stocker 100000 fois (si le site fait 100000 pages) la meme entete, la meme barre de menu, le meme footer etc etc. Et au final on en vient a régénerer sur le disque une version statique du site ... alors que dans le meme temps on va pinailler dans la bdd entre INT et LONGINT !!!! Pas très cohérent.
Parce que sur le fond, la mise en cache à pour objectif principal si j'ai pas sauté une marche de soulager la charge serveur au niveau des sollicitations de la base de données et, accessoirement de profiter d'un affichage plus rapide des pages puisque pas / ou moins de requete sql et moins de code de fabrication des eléments de mises en page.
Ayant posé ces postulat, j'en suis venu a commencer a me poser la question "quelle partie des pages mérite d'être mise en cache" ... Plutot qu'un long discours, deux exemples concret avec 1 page a l'url fixe "index.php" et une autre page "rewritée".
La page index de mon www :
Url pour la voir en real : http://www.qui-est-le-meilleur.com
Si je tiens compte des constat ci-dessus, j'en arrive a considérer :
- toute la partie haute (cadre violet) non cachable (du pur statique donc zero economie mysql).
- la partie centrale (cadre vert) tout a fait dans la cible (y a deux requetes sql a gratter) et l'affichage ets le meme que l'on soit visiteur ou memebre inscrit.
- la partie basse (cadre rouge) mérite analyse car elle me consomme elle aussi 2 requetes sql la bougresse ... sauf que ca bouge tellement tout le temps (dès qu'un membre se gratte le nez ca fait bouger un truc la dedans) que l'on passerait plus de temps a supprimer/recréer le cache qu'à l'exploiter ... donc on l'oublie.
- Reste tout en haut d el'ecran la mention du connecté/non connecté. Par definition on l'oublie puisque l'on veut du cache "tout terrain" : inscrit / non inscrit / bot sans distinction.
UNe page de type histo :
Url pour la voir en real : http://www.qui-est-le-meilleur.com/historique-2011-05-11.php
Si je choisi ce type de page, c'est que d'une part est elle simple dans son contenu (toujours plus facile dans le cadre d'explication ecrites) et que c'est une page avec paramètres et donc rewritée (contrairement a index.php ci-dessus). et cela a son importance pour la suite ... Mais non je plaisante : on se tappe royalement du rewriting (vou spouvez chager 10 fois vos régles dan sle htaccess sans impact sur la gestion du cache puisque ce ne sont pas des pages mais des "paquets de data" que l'on va mettre en cache ... et a qui on donne un petit nom deconnecté du rewriting (enfin en cohérence quand meme ...)
Selon la meme logique que ci-dessus on en vient a conclure que la seule partie cachable sera le cadre central (de toute façon c'est le seul qui consomme 1 requete mysql dans la page). En plus ce type de page a un gros avantage dans le cadre d'un cache : son cache est éternel ... puisque une fois une journée finie, ca ne bouge plus ...
Note : la on raisonne pour l'exempel sur une page qui consomme une micro requete sql et une seule donc l'impact sera faible mais le meme raisonnement s'applqiue sur un bloc necessitant quelques grosses requetes gourmandes avec jointure et tout et tout ...
MISE EN MUSIQUE
Bon ben ayant posé comme postulat que l'on ne gérait plus du cache de pages php mais du cache de morceau de pages, restait à le coder en essayant de mettre un place un truc facile a implanter avec un minimum de code (ma flemme est désormais bien connue donc autant y faire honneur) et offrant toute souplesse de choix pour chaque type de page ... Bref le beurre, les dihrams et la chamelière en prime ! Oui oui c'est une version locale que je viens d'inventer ...
Et finalement ca commence plutot bien puisque tout mon systeme de cache va reposer sur 5 petits script de 4 à 6 lignes ! Pourquoi faire plus si on peut faire moins ... Allez un peu de code lisible même par les phprank1 :
Cache_ecrire.php
Ca va pas trop fatigué le chat ? nan nan ca va ...
Cache_lire.php
Ouai là non plus pas de callosités sous les indexes !
Cache_detruire.php
Note : ici on peut choisir d'autres options (ne pas detruire mais réécrire vide), ou encore ne rien toucher à part ecraser le premier octet du document avec une "*" d'invalidation (ultra vite ecrit et vite testé ...). Perso en prod je pense que c'est cette option que je choisirai ... il suffira de changer la façon de tester dans cache_lire ...
Arrête zecat, tu frises la suractivité et l'usure prématurée du clavier ...
Cache_affiche.php
Houla vite une chaise longue ...
cache_impacter.php
Voila c'est tout. Toutes les routines sont en place.
MISE EN APPLICATION SUR LA PAGE INDEX.PHP
Son code (avant gestion cache) est simple (j'ai juste renommé les scripts pour la clarté mais c'est tout) :
On a vu que la seule partie de la page qui nous intéresse au titre de la mise en cache est actus_ajouts ... je modifie donc cette page ainsi :
et on mets actus_ajouts dans le switch de cache_affiche à la place de aaaaaa ..
(le premier case) :
En gros je décide de donner un zouli petit nom à ce bloc et je l'appelle, notez l'originalité et la recherche "cache_index_1" (1 c'est parce que rien n'interdit d'avoir demain un autre bloc cache dans cette même page ... on le nommera surement ... cache_index_2 !
VOILA C'EST FINI ... OU PRESQUE ...
On lance désormais index.php sur notre navigateur ... cadre_affiche est lancé. il regarde si il a le nom demandé en stock (cache_index_1) ... Nada ! Donc il passe en mode "tampon" et execute le code normal "actus_ajouts.php" puis le balance sur le disque (cache_ecrire) et l'affiche normalement. Les encadrements par "." et ".." c'est juste pour voir les scripts agir en phase debug. On vient donc de génerer le cache du morceau voulu (que le visiteur soit un bot, un visiteur ou un inscrit). On pourra juste ajouter un if (gooogloubot) pas d'ecriture cache (histoire de travailler sa courbe dans GWT).
Maintenant votre voisine de palier arrive aussi sur cette page, ca execute cache_affiche, qui trouve le cache demandé et donc cache_lire lit et affiche le morceau voulu avec "readfile($cache_chemin);" et saute le reste.
Pour la page historique c'est le meme principe sauf que comme c'est une page avec un parametre en entrée le code devient :
La page avant :
La page apres :
Vous noterez la seule différence avec la page index : on passe une valeur date du jour dans $cache_param (pas mis direct dans cache_nom pour que l'on reste dans un seul case au niveau du switch. Et le second switch de case_affiche :
Voila nous disposons d'un systeme de cache permettant de couvrir les pages a url fixe et les pages avec paramètres ... en prenant en cache dans les pages le ou les paquets qui nous intéressent ...
PAS DE DUREE DE VIE A PRIORI
Ben non ! Un morceau en cache n'a aucune raison de sortir de sa cachette (ah c'est malin ...) tant qu'on le laisse dormir ... Certains caches seront éternels (cf historiques) et d'autres à durée de vie plus courte (cf index). Et donc toute la question est : qui va être autorisé à décider que tel morceau de cache est obsolète et doit mourir ... Et je reconnais que c'est la que ca devient un peu plus casse-machins à formaliser de façon aussi simple et tout terrain ... Enfin tout est relatif puisque c'est le script cache_impacter.php qui se chargera du truc ...
MISE A JOUR DU CACHE
Le principe est tout simplement pour chaque fonction (les post via formulaire en général) de se demander "quel(s) cache(s) cette action doit elle impacter" (impacter ca veut dire supprimer !).
J'ai donc un en validation de mon formulaire d'ajout de nouveaux prestataires un submit qui lance "prestataire_ajout_pos.php". Son allure est en gros (je saute les etapes de verif et l'enrobage de filtrage etc) :
Cette fonction va avoir un impact sur le cache index et sur le cache histo du jour concerné ... je vais donc ajouter quelques lignes à mon script qui devient :
Et donc dès lors qu'un utilisateur ajoute une fiche, cache_impacter va se charger de faire le menage ...
Note : j'ai mis la page histo juste pour la comprehension parce que en fait, dans ce cas particulier, je vais en amont tout simplement ne pas chercher de cache lorsque l'on affiche la page du jour courant ... donc aucun besoin d'impacter avec une saisie forcément dans le jour courant ...
Voila y a tout ...
LA VERSION DE CACHE
J'allais oublier ... Vous aurez noté que l'on range les caches non pas dans un dossier CACHE mais CACHE_V01 (si $cache_version a été initalisée avec "V01"). C'est tout simplement pour faciliter une opération de purge totale du cache (pour telle ou tele raison, peut importe).
Il suffit donc de changer la valeur de $cache_version en "V02" et tout le cahe se déroute vers un nouveau dossier (vide) CACHE_V02 ... Ce qui laisse tout loisirs de virer un peu plus tard sans stress le dossier CACHE_V01 en 2 clics via son cpanel par exemple ...
C'est tout chaud en cours de test (fonctionnel ... je vous aurais pas mis du code qui plante !) et donc si vous avez des remarques ou suggestions ... (y a surement des petites optimisations de code ou de méthodologie que j'ai sauté ....).
L'intéret : c'est tout léger, sans impact au niveau rewriting et très souple pour s'adapter à de multiples cas de figure en englobant des parties plus ou moins grande des pages dans les caches, tout en ne stockant pas de trop gros volumes sur le disque du serveur ... et ca se met en place en quelques minutes sans se poser de question : on pose les 5 scripts à la racine de son site et on peut commencer a "cacher" ses premier morceaux de page ... Enfin moi je le sens ainsi :wink:
Ouf je suis au bout du topic ... allez hop clic sur ENVOYER ! Faites pas gaffe aux fautes de frappes, vu la longueur ...
Ben oui, comme d'habitude, il faut que je me fasse les trucs à ma sauce :!: J'ai lu l'enorme topic épinglé sur le sujet ... ainsi que les multiples variantes et alternatives proposées sur des sites linkés par ce topic ... Interessant mais usant ... vu la taille du topic ...
Ce que j'en retiens est que la mise en cache de page entière ne me convient pas :
1 - Ca implique que seule la version visiteur non inscrits/connecté est "cachable" et que donc seuls les visiteurs non inscrits sont concernés (tant sur le plan vitesse pour eux que sur le plan décharge de la bdd par eux). Les membres inscrits eux auront un affichage plus lent et se traduiront par une charge supérieure ... Pas glop pas glop ...
2 - Qu'il vous vienne à l'idée d'ajouter une "*" sur un élément présent sur toutes les les pages (style un onglet de plus dans la barre de menu ou même n'importe quel element statiques dans les pages) et hop c'est tout votre cache (ou toutes le spages ayant en commun cet élément statique) qui devient obsolète et part à la benne ... et devra être regénéré (soit massivement soit petit a petit au gré des affichages de page).
3 - Il est des contextes (mutu) ou la place sur disque est aussi comptée et donc mettre l integralité de la page en cache revient a stocker 100000 fois (si le site fait 100000 pages) la meme entete, la meme barre de menu, le meme footer etc etc. Et au final on en vient a régénerer sur le disque une version statique du site ... alors que dans le meme temps on va pinailler dans la bdd entre INT et LONGINT !!!! Pas très cohérent.
Parce que sur le fond, la mise en cache à pour objectif principal si j'ai pas sauté une marche de soulager la charge serveur au niveau des sollicitations de la base de données et, accessoirement de profiter d'un affichage plus rapide des pages puisque pas / ou moins de requete sql et moins de code de fabrication des eléments de mises en page.
Ayant posé ces postulat, j'en suis venu a commencer a me poser la question "quelle partie des pages mérite d'être mise en cache" ... Plutot qu'un long discours, deux exemples concret avec 1 page a l'url fixe "index.php" et une autre page "rewritée".
La page index de mon www :
Url pour la voir en real : http://www.qui-est-le-meilleur.com
Si je tiens compte des constat ci-dessus, j'en arrive a considérer :
- toute la partie haute (cadre violet) non cachable (du pur statique donc zero economie mysql).
- la partie centrale (cadre vert) tout a fait dans la cible (y a deux requetes sql a gratter) et l'affichage ets le meme que l'on soit visiteur ou memebre inscrit.
- la partie basse (cadre rouge) mérite analyse car elle me consomme elle aussi 2 requetes sql la bougresse ... sauf que ca bouge tellement tout le temps (dès qu'un membre se gratte le nez ca fait bouger un truc la dedans) que l'on passerait plus de temps a supprimer/recréer le cache qu'à l'exploiter ... donc on l'oublie.
- Reste tout en haut d el'ecran la mention du connecté/non connecté. Par definition on l'oublie puisque l'on veut du cache "tout terrain" : inscrit / non inscrit / bot sans distinction.
UNe page de type histo :
Url pour la voir en real : http://www.qui-est-le-meilleur.com/historique-2011-05-11.php
Si je choisi ce type de page, c'est que d'une part est elle simple dans son contenu (toujours plus facile dans le cadre d'explication ecrites) et que c'est une page avec paramètres et donc rewritée (contrairement a index.php ci-dessus). et cela a son importance pour la suite ... Mais non je plaisante : on se tappe royalement du rewriting (vou spouvez chager 10 fois vos régles dan sle htaccess sans impact sur la gestion du cache puisque ce ne sont pas des pages mais des "paquets de data" que l'on va mettre en cache ... et a qui on donne un petit nom deconnecté du rewriting (enfin en cohérence quand meme ...)
Selon la meme logique que ci-dessus on en vient a conclure que la seule partie cachable sera le cadre central (de toute façon c'est le seul qui consomme 1 requete mysql dans la page). En plus ce type de page a un gros avantage dans le cadre d'un cache : son cache est éternel ... puisque une fois une journée finie, ca ne bouge plus ...
Note : la on raisonne pour l'exempel sur une page qui consomme une micro requete sql et une seule donc l'impact sera faible mais le meme raisonnement s'applqiue sur un bloc necessitant quelques grosses requetes gourmandes avec jointure et tout et tout ...
MISE EN MUSIQUE
Bon ben ayant posé comme postulat que l'on ne gérait plus du cache de pages php mais du cache de morceau de pages, restait à le coder en essayant de mettre un place un truc facile a implanter avec un minimum de code (ma flemme est désormais bien connue donc autant y faire honneur) et offrant toute souplesse de choix pour chaque type de page ... Bref le beurre, les dihrams et la chamelière en prime ! Oui oui c'est une version locale que je viens d'inventer ...
Et finalement ca commence plutot bien puisque tout mon systeme de cache va reposer sur 5 petits script de 4 à 6 lignes ! Pourquoi faire plus si on peut faire moins ... Allez un peu de code lisible même par les phprank1 :
Cache_ecrire.php
Code:
<?php
$cache_tampon = ob_get_contents();
if(!is_dir($cache_dossier)) { mkdir ($cache_dossier); }
$cache_ref = fopen ($cache_chemin, "w+");
fputs ($cache_ref, $cache_tampon);
fclose ($cache_ref);
?>Cache_lire.php
Code:
<?php
$cache_dossier=$_SERVER["DOCUMENT_ROOT"].'/CACHE_'.$cache_version.'/';
$cache_document=$cache_nom.$cache_param.'.php';
$cache_chemin=$cache_dossier.$cache_document;
if(file_exists($cache_chemin))
{
echo("."); // debug : signalement debut lu dans cache
readfile($cache_chemin);
echo(".."); // debug : signalement fin lu dans cache
$cache_trouve=true;
}
else { $cache_trouve=false; }
?>Ouai là non plus pas de callosités sous les indexes !
Cache_detruire.php
Code:
<?php
$cache_dossier=$_SERVER["DOCUMENT_ROOT"].'/CACHE_'.$cache_version.'/';
$cache_document=$cache_nom.'.php';
$cache_chemin=$cache_dossier.$cache_document;
if(file_exists($cache_chemin))
{
echo("Suppression du cache : ".$cache_document."<br>");
$cache_ouverture = opendir ($cache_dossier);
unlink ($cache_chemin);
closedir ($cache_ouverture);
}
?>Note : ici on peut choisir d'autres options (ne pas detruire mais réécrire vide), ou encore ne rien toucher à part ecraser le premier octet du document avec une "*" d'invalidation (ultra vite ecrit et vite testé ...). Perso en prod je pense que c'est cette option que je choisirai ... il suffira de changer la façon de tester dans cache_lire ...
Arrête zecat, tu frises la suractivité et l'usure prématurée du clavier ...
Cache_affiche.php
Code:
<?php
include("cache_lire.php"); // on regarde si il existe et on l'affiche si oui
if(!$cache_trouve) // si pas de cache trouvé
{
echo("<u>.</u>"); // debug : signalement debut fab cache
ob_start(); // debut mise en tampon
switch ($cache_nom)
{
case 'cache_aaaaaa_1':
include("aaaaaa_cache_fab_1.php"); // fabrication morceau 1 de page aaaaaa
break;
case 'cache_bbbbbb_1':
include("bbbbbb_cache_fab_1.php"); // fabrication cadre central page bbbbbb
break;
}
include("cache_ecrire.php"); // on ecrit le cache sur disque
ob_end_clean(); // arret mise en tampon
echo($cache_tampon); // on affiche ce qu'on vient de fabriquer
echo("<u>..</u>"); // debug : signalement fin fab cache
}
?>cache_impacter.php
Code:
<?php
$cache_dossier=$_SERVER["DOCUMENT_ROOT"].'/CACHE_'.$cache_version.'/';
if(is_dir($cache_dossier))
{
$ouverture = opendir ($cache_dossier);
echo("Impact cache : "); // echo de debug
foreach($tab_cache_impact as $cache_document)
{
echo($cache_document."/"); // echo de debug
$cache_chemin=$cache_dossier.$cache_document;
if(file_exists($cache_chemin)) { unlink ($cache_chemin); }
}
closedir ($ouverture);
}
?>Voila c'est tout. Toutes les routines sont en place.
MISE EN APPLICATION SUR LA PAGE INDEX.PHP
Son code (avant gestion cache) est simple (j'ai juste renommé les scripts pour la clarté mais c'est tout) :
Code:
<?php
include ("entete.php");
include ("menu.php");
include ("presentation.php");
include ("actus_ajouts.php");
include ("cadre_qui.php");
include("affiche_pied_haut.php");
?>On a vu que la seule partie de la page qui nous intéresse au titre de la mise en cache est actus_ajouts ... je modifie donc cette page ainsi :
Code:
<?php
include ("entete.php");
include ("menu.php");
include ("presentation.php");
$cache_nom="cache_index_1";
include("cache_affiche.php");
include ("cadre_qui.php");
include("affiche_pied_haut.php");
?>et on mets actus_ajouts dans le switch de cache_affiche à la place de aaaaaa ..
(le premier case) :
Code:
case 'cache_index_1:
include("actus_ajouts.php");En gros je décide de donner un zouli petit nom à ce bloc et je l'appelle, notez l'originalité et la recherche "cache_index_1" (1 c'est parce que rien n'interdit d'avoir demain un autre bloc cache dans cette même page ... on le nommera surement ... cache_index_2 !
VOILA C'EST FINI ... OU PRESQUE ...
On lance désormais index.php sur notre navigateur ... cadre_affiche est lancé. il regarde si il a le nom demandé en stock (cache_index_1) ... Nada ! Donc il passe en mode "tampon" et execute le code normal "actus_ajouts.php" puis le balance sur le disque (cache_ecrire) et l'affiche normalement. Les encadrements par "." et ".." c'est juste pour voir les scripts agir en phase debug. On vient donc de génerer le cache du morceau voulu (que le visiteur soit un bot, un visiteur ou un inscrit). On pourra juste ajouter un if (gooogloubot) pas d'ecriture cache (histoire de travailler sa courbe dans GWT).
Maintenant votre voisine de palier arrive aussi sur cette page, ca execute cache_affiche, qui trouve le cache demandé et donc cache_lire lit et affiche le morceau voulu avec "readfile($cache_chemin);" et saute le reste.
Pour la page historique c'est le meme principe sauf que comme c'est une page avec un parametre en entrée le code devient :
La page avant :
Code:
<?php
...
include ("historique_liste.php");
...
?>La page apres :
Code:
<?php
...
$cache_param="_".date('Ymd');
$cache_nom="cache_historique_1";
include("cache_affiche.php");
...
?>Vous noterez la seule différence avec la page index : on passe une valeur date du jour dans $cache_param (pas mis direct dans cache_nom pour que l'on reste dans un seul case au niveau du switch. Et le second switch de case_affiche :
Code:
case 'cache_historique_1':
$date_histo=$cache_param;
include ("historique_liste.php");Voila nous disposons d'un systeme de cache permettant de couvrir les pages a url fixe et les pages avec paramètres ... en prenant en cache dans les pages le ou les paquets qui nous intéressent ...
PAS DE DUREE DE VIE A PRIORI
Ben non ! Un morceau en cache n'a aucune raison de sortir de sa cachette (ah c'est malin ...) tant qu'on le laisse dormir ... Certains caches seront éternels (cf historiques) et d'autres à durée de vie plus courte (cf index). Et donc toute la question est : qui va être autorisé à décider que tel morceau de cache est obsolète et doit mourir ... Et je reconnais que c'est la que ca devient un peu plus casse-machins à formaliser de façon aussi simple et tout terrain ... Enfin tout est relatif puisque c'est le script cache_impacter.php qui se chargera du truc ...
MISE A JOUR DU CACHE
Le principe est tout simplement pour chaque fonction (les post via formulaire en général) de se demander "quel(s) cache(s) cette action doit elle impacter" (impacter ca veut dire supprimer !).
J'ai donc un en validation de mon formulaire d'ajout de nouveaux prestataires un submit qui lance "prestataire_ajout_pos.php". Son allure est en gros (je saute les etapes de verif et l'enrobage de filtrage etc) :
Code:
<?php
include("sql_base_open.php");
include("sql_prestataire_add.php");
include("sql_base_close.php");
?>Cette fonction va avoir un impact sur le cache index et sur le cache histo du jour concerné ... je vais donc ajouter quelques lignes à mon script qui devient :
Code:
<?php
include("sql_base_open.php");
include("sql_prestatire_add.php");
include("sql_base_close.php");
// ----- tableau des impacts sur cache de la fonction ajouter prestataire
$tab_cache_impact=array();
$tab_cache_impact[]='cache_index_1.php'; // le cadre derniers ajouts
$tab_cache_impact[]='cache_historique_1'.'_'.date('Ymd').'.php'; // la page histo du jour
include("cache_impacter.php");
?>Et donc dès lors qu'un utilisateur ajoute une fiche, cache_impacter va se charger de faire le menage ...
Note : j'ai mis la page histo juste pour la comprehension parce que en fait, dans ce cas particulier, je vais en amont tout simplement ne pas chercher de cache lorsque l'on affiche la page du jour courant ... donc aucun besoin d'impacter avec une saisie forcément dans le jour courant ...
Voila y a tout ...
LA VERSION DE CACHE
J'allais oublier ... Vous aurez noté que l'on range les caches non pas dans un dossier CACHE mais CACHE_V01 (si $cache_version a été initalisée avec "V01"). C'est tout simplement pour faciliter une opération de purge totale du cache (pour telle ou tele raison, peut importe).
Il suffit donc de changer la valeur de $cache_version en "V02" et tout le cahe se déroute vers un nouveau dossier (vide) CACHE_V02 ... Ce qui laisse tout loisirs de virer un peu plus tard sans stress le dossier CACHE_V01 en 2 clics via son cpanel par exemple ...
C'est tout chaud en cours de test (fonctionnel ... je vous aurais pas mis du code qui plante !) et donc si vous avez des remarques ou suggestions ... (y a surement des petites optimisations de code ou de méthodologie que j'ai sauté ....).
L'intéret : c'est tout léger, sans impact au niveau rewriting et très souple pour s'adapter à de multiples cas de figure en englobant des parties plus ou moins grande des pages dans les caches, tout en ne stockant pas de trop gros volumes sur le disque du serveur ... et ca se met en place en quelques minutes sans se poser de question : on pose les 5 scripts à la racine de son site et on peut commencer a "cacher" ses premier morceaux de page ... Enfin moi je le sens ainsi :wink:
Ouf je suis au bout du topic ... allez hop clic sur ENVOYER ! Faites pas gaffe aux fautes de frappes, vu la longueur ...
Perso j'ai un cache global dont je gère la réactualisation, et un cache spécifique (un champ dans une table) où la réactualisation est encore moins fréquente (liens internes)
