Utilisation intensive de la mise en cache des pages PHP.

[thierry8]

Bonjour,

Je n'ai pas continué sur le fil de fandecine qui fait l'objet de la question, pour bien dissocier l'objectif du post.

Je souhaiterai savoir s'il est possible d'utiliser de manière intensive ce genre de script ?

Un exemple des plus concret: un forum comme WRI.

- Qu'en pensez-vous ? Toutes vos remarques sont les bienvenues.
- Ne risque t-il pas d'y avoir des problèmes ? (le fichier à peine créé, il faut le supprimer, etc...)

[spidetra]

Pour le script de fandecine, aucune idée, jamais testé.

Il n'y a aucune contre-indication à l'utilisation intensive de systèmes de caches, bien au contraire.

Tout les langages (Php, Java, dotNet, etc..) doivent avoir aujourd'hui des systèmes de gestion de cache.

Tu peux aussi déléguer la gestion de ton cache à des serveurs extérieurs à ton appli :
- ton serveur SGBD, a surement un système de cache de requetes
- ton serveur web ( disons Apache ), a surement un systeme de de gestion de cache ( mod_proxy)
- mettre en place un serveur de proxy du type SQUID


Si tu fait du cache de page entière. Ne t'embête pas. Délégue la gestion de ton cache à Apache ou a Squid.

Si tu veux gérer ton cache plus finement, cache par fragment de page, cache de fonction..., tu devras gérer ton cache par programmation.

[Delapouite]

Il y'a déja un premier soucis qui se pose.

Dans la colonne de gauche, sous le pseudo de chaque membre apparait son nombre de contributions total.
Ce nombre ne peut pas etre mis en cache car il évolue sans cesse dès que la personne intervient quelque part sur le forum.

Pour l'instant je ne vois pas trop de solution à moins de ne cacher que la colonne de droite contenant les messages. Or, dans la construction des tableaux html, le balisage se fait par ligne et non pas par colonne. Il faudrait donc revoir la structure avec deux floats juxtaposés. Mais dans ce cas comment faire coincider verticalement les membres avec la hauteur des posts variables ?

[thierry8]

Il y'a déja un premier soucis qui se pose.

Dans la colonne de gauche, sous le pseudo de chaque membre apparait son nombre de contributions total.
Ce nombre ne peut pas etre mis en cache car il évolue sans cesse dès que la personne intervient quelque part sur le forum.

Pour l'instant je ne vois pas trop de solution à moins de ne cacher que la colonne de droite contenant les messages. Or, dans la construction des tableaux html, le balisage se fait par ligne et non pas par colonne. Il faudrait donc revoir la structure avec deux floats juxtaposés. Mais dans ce cas comment faire coincider verticalement les membres avec la hauteur des posts variables ?

Là n'est pas la question.
Il y a largement possibilité de trouver une solution.

Pour spidetra, je demande bien une gestion des pages PHP en cache grâce à un script tel que fandecine la proposé.
Pour ceux qui ne peuvent contrôler leur serveur.

La question est principalement dirigée vers le soucis de création intensif de pages. En effet si un forum est très vivant, on connait le problème "Trop de connexions simultanées à Mysql". Or, le système de cache est normalement censé remèdier plus ou moins à ce genre de problème.
Mais ne peut-il lui même pas soumettre d'autres problèmes ?

Un exemple:
Plusieurs utilisateurs en même temps effectue une requete sur un même post (que ce soit création d'une réponse, édition, etc...). Ne risque t-il pas d'y avoir des problèmes du genre:
- fichier vide
- fichier incomplet
- fichier bloqué

[spidetra]

Il y'a déja un premier soucis qui se pose.

Dans la colonne de gauche, sous le pseudo de chaque membre apparait son nombre de contributions total.
Ce nombre ne peut pas etre mis en cache car il évolue sans cesse dès que la personne intervient quelque part sur le forum.

En quoi c'est un problème ?

Voici un exemple de script php, qui met en cache 2 blocs et qui affiche l'heure courante.
L'heure courante ne peut évidemmment pas être mis en cache.
On ne met en cache que des fragments de la page.

Code: Tout sélectionner

<?php
// On charge Cache_Lite
require_once('Cache/Lite/Output.php');

// On fixe un identifiant pour le premier bloc
$id1 = 'divisible_par_7';

// On fixe un identifiant pour le deuxième bloc
$id2 = 'divisible_par_9';

// On définit quelques options :
// - le répertoire où seront stockés les fichiers de cache
// - la durée de vie du cache (ici 30 secondes)
$options1 = array(
  'cacheDir' => '/tmp/',
  'lifeTime' => 30
  );

$options2 = array(
  'cacheDir' => '/tmp/',
  'lifeTime' => 45
  );

// On crée deux objets Cache_Lite_Output avec les bonnes options
$Cache_Lite_Output1 = new Cache_Lite_Output($options1);
$Cache_Lite_Output2 = new Cache_Lite_Output($options2);

// Gestion du bloc 1
if (!($Cache_Lite_Output1->start($id1))) {
  for($i = 0 ; $i<10000 ; $i++) {
    if (($i % 7)==0) {
      echo($i);
      echo('<br>');
      }
    }
  $Cache_Lite_Output1->end();
  }

// Attention, partie dynamique non cachée :
echo(date('H:i:s'));
echo('<br>');

// Gestion du bloc 2
if (!($Cache_Lite_Output2->start($id2))) {
  for($i = 0 ; $i<10000 ; $i++) {
    if (($i % 9)==0) {
      echo($i);
      echo('<br>');
      }
    }
  $Cache_Lite_Output2->end();
  }
?>


[spidetra]

Pour spidetra, je demande bien une gestion des pages PHP en cache grâce à un script tel que fandecine la proposé.
Pour ceux qui ne peuvent contrôler leur serveur.

en PHP des solutions somme PEAR::Cache vont régler ton pb. Ne gère pas tout à la main.
Il n'existe pas que PEAR, il existe d'autres systèmes de cache en php. A toi de voir ceui qui est le plus adapté à tes projets

[thierry8]

Je vais voir ça. En effet j'ai fais un tour sur ton lien qui demeurre interessant.
Cependant qu'apporte de plus une class comme celle de PEAR ?
(je veux dire, n'y a t-il pas peut être des truc pas forcément utile)

Tandis que la solution comme fandecine, on peut plus facilement la maîtriser.
De plus ce doit être le même système, non ?
(je dis cela, car je n'aime pas trop être dépendant, d'autre chose,
si un bug, il faut faire une mise à jour, etc...or sur "notre" sytème on sait,
on test, donc à priori pas de problème, mais des améliorations possible, là
est toute la différence)

Mais je vais voir tout ça, mais si tu peux m'en dire plus, vue que tu l'utilise.

[dcz]

Pour phpbb, il y a aussi le systeme de cache sql de www.phpbbstyles.com qui marche très bien.

++

[spidetra]

Mais je vais voir tout ça, mais si tu peux m'en dire plus, vue que tu l'utilise.

Je développe de moins en moins en PHP aujourd'hui.
Notre framework était largement basé sur PEAR. Donc pour la gestion du cache nous utilisions PEAR::Cache. Je n'ai jamais rencontré de pb avec cette solution.

[thierry8]

Je suis entrain de lire un peu le code de la class PEAR, ainsi que le lien que tu as donné.
Cependant, lorsque l'on souhaite que la page n'expire jamais, comment faire ?
(de manière à gérer soit même, on effeace le fichier lorsqu'une nouvelle version existe)

[spidetra]

LifeTime => durée de vie du cache courant.
Cache_Lite::setLifeTime() => Modifie la durée de vie du cache courant
Cache_Lite::remove() : Supprimmer un fichier donné

http://pear.php.net/manual/fr/package.c ... e-lite.php

[thierry8]

Merci.

Je viens de tomber dessus !

En revanche, il n'y a pas indiquer pour une durée illimitée dans le temps...
Tu faisait comment toi ?
Un chiffre énorme ?

EDIT:
Un autre truc encore ou j'ai besoin d'un coup de pouce:
(peut être as tu également été confronté à ce problème)

Lorsque l'on regroupe toutes ces requêtes à un endroits et qu'on ne les traite qu'après avoir fermé la connexion à mysql, comment faire ?
exemple:

Code: Tout sélectionner

<?php
// connexion mysql
// traitement mysql
// fermeture mysql

// gérer les données
// aficher, etc...
?>

Comment faire pour ne pas executer les requêtes mysql ?
files_exist, humm...je ne pense pas que cela puisse aller du fait que la class PEAR intègre d'autre paramètre (vérification fichier, durée de vie).
Suffit que le fichier soit éroné ou que la durée de vie soit passé de l'instant de vérification au niveau mysql jusqu'a son traitement.

Il faut prendre en compte qu'il y a plusieurs requêtes mysql, et donc plusieurs bloc.

La solution serai pour chacun des blocs ouvrir une connexion mysql puis refermer...mais pas terrible quand même...

[spidetra]

Je gérais des durée de vie en fonction de la nature des blocs ou des pages :

Exemple ( de mémoire ):
- page d'accueil : durée de vie 30 mn
- bloc : les 10 derniers trucs ou bidule : 15 mn
- bloc : mise en avant produit : 1 Heure
- page de news : quelques heures
- page peu modifiée : durée de vie de un mois.

si tu veux de l'illimité tu prend une durée longue > 1 mois, ça devrait faire l'affaire.

[thierry8]

Je gérais des durée de vie en fonction de la nature des blocs ou des pages :

Exemple ( de mémoire ):
- page d'accueil : durée de vie 30 mn
- bloc : les 10 derniers trucs ou bidule : 15 mn
- bloc : mise en avant produit : 1 Heure
- page de news : quelques heures
- page peu modifiée : durée de vie de un mois.

si tu veux de l'illimité tu prend une durée longue > 1 mois, ça devrait faire l'affaire.

Par contre on est bien d'accord sur le fait que la durée de vie ne permet pas d'effacer les fichiers qui ne sont plus utile après leur durée, que dans le cas ou ce fichier est demandé, c'est bien cela ?

Si le fichier n'est pas demandé et que sa durée de vie à expiré, il ne sera pas supprimé automatiquement...

[spidetra]

Comment faire pour ne pas executer les requêtes mysql ?

Le rôle du cache est justement de ne pas excécuter les requêtes SQL.
Tu n'éxécute une requête SQL qu'après avoir vérifié l'expiration ou non du cache :

Code: Tout sélectionner

<?php
// On charge Cache_Lite
require_once('Cache/Lite/Output.php');

// On fixe un identifiant pour le premier bloc
$id1 = 'divisible_par_7';

// On fixe un identifiant pour le deuxième bloc
$id2 = 'divisible_par_9';

// On définit quelques options :
// - le répertoire où seront stockés les fichiers de cache
// - la durée de vie du cache (ici 30 secondes)
$options1 = array(
  'cacheDir' => '/tmp/',
  'lifeTime' => 30
  );

$options2 = array(
  'cacheDir' => '/tmp/',
  'lifeTime' => 45
  );

// On crée deux objets Cache_Lite_Output avec les bonnes options
$Cache_Lite_Output1 = new Cache_Lite_Output($options1);
$Cache_Lite_Output2 = new Cache_Lite_Output($options2);

// Gestion du bloc 1
if (!($Cache_Lite_Output1->start($id1))) {
  // C'est ici que tu excécute ta requete SQL pour ce Bloc
      }
    }
  $Cache_Lite_Output1->end();
  }
...... etc....
?>


Pour l'ouverture de la connexion à toi de voir comment faire :
- début de script
- dans chaque bloc

Perso, j'ouvrais et je refermait les cnx dans chaque bloc.
C'est peut-être pas la meilleure solution.
ça posait pas vraiment de pb, dans la mesure ou les blocs était mis en cache