Utilisation intensive de la mise en cache des pages PHP.

thierry8 · 1 Mars 2006

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 · 1 Mars 2006

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 · 1 Mars 2006

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 · 1 Mars 2006

Delapouite a dit:
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 · 1 Mars 2006

Delapouite a dit:
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:

<?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 · 1 Mars 2006

thierry8 a dit:
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 · 1 Mars 2006

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 · 1 Mars 2006

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

++

spidetra · 1 Mars 2006

thierry8 a dit:
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 · 1 Mars 2006

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 · 1 Mars 2006

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 · 1 Mars 2006

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:

<?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 · 1 Mars 2006

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 · 1 Mars 2006

spidetra a dit:
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 · 1 Mars 2006

thierry8 a dit:
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:

<?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

thierry8 · 1 Mars 2006

ok ! Merci !
Je vais encore voir pour ce point !

thierry8 · 1 Mars 2006

thierry8 a dit:
spidetra a dit:

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.

Cliquez pour agrandir...

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...

et pour cela ?
Est-ce que j'ai bien compris le système ?

thierry8 · 1 Mars 2006

Auto-réponse:

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

Active le processus de nettoyage automatique. Le processus de nettoyage automatique supprime tous les fichers de cache qui ont expiré selon le temps de vie indiqué. Il est déclanché quand un nouveau fichier de cache est écrit. 0 signifie "pas de nettoyage automatique", 1 signifie "nettoyage automatique systématique" (lent), x>1 signifie "nettoyage automatique 1 fois sur x écritures de cache". Une valeur entre 20 et 200 est une bonne valeur pour commencer.

On peut choisir ! Que demander de plus !!! :lol:

thierry8 · 1 Mars 2006

En revanche il y a un fichier PEAR.php, qui est ouvert lors de problème.
Mais ce fichier n'est pas dans le package.
Sais tu pourquoi ?
As-tu supprimé le require de ce fichier ?

spidetra · 2 Mars 2006

thierry8 a dit:
En revanche il y a un fichier PEAR.php, qui est ouvert lors de problème.
Mais ce fichier n'est pas dans le package.
Sais tu pourquoi ?
As-tu supprimé le require de ce fichier ?

Les packages PEAR ont des dépendances entre eux.
Tout les packages PEAR dépendent du package de base : PEAR.php

tu as des tutos d'installation de PEAR qui vont t'aider.

thierry8 · 2 Mars 2006

Oui j'ai vu désolé, j'aurais du éditer ici.

En revanche à tu une idée de comment paramètrer le critère: hashedDirectoryLevel

Définit le degré de structure du dossier de hashage 0 signifie "aucune structure de dossier de hashage", 1 signifie "Un niveau de dossiers", 2 signifie "deux niveaux"... Cette option peut accélérer Cache_Lite uniquement lorsque vous avez plusieurs centaines de fichiers de cache. Seul des essais peuvent vous aider à choisir la valeur parfaite pour votre cas. Probablement qu'une valeur à 1 ou 2 est bon pour commencer.

Je ne comprend pas très bien l'utilité.

Merci à toi.

spidetra · 2 Mars 2006

Je n'ai jamais touché à cette option.
Elle te permet de régler la profondeur de l'arborescence de ton système de cache.
Unix est un système massivement arborescent.
Tu auras de meilleurs performances en répartissant des fichiers sur plusieurs niveaux plutot qu'en mettant tout tes fichiers dans un meme repertoire.
Suit les conseils et met un premier niveau à 1 ou 2.
Si demain la taille de ton cache devient très grande tu pourras augmenter cette valeur.

thierry8 · 2 Mars 2006

ok.

merci beaucoup pour toutes ces informations.
:wink:

yakipa · 16 Mai 2006

QQun a deja essayé APC ?

j'ai des sites qui ont des grosses requetes SQL (comparateur de prix, site de news via des bases sql, etc).

c'est une bonne chose d'installer APC a votre avis histoire d'alléger tout ca ?

aour · 18 Juin 2006

Bonjour,

Je vais mettre mon petit grain de sable mais TinybutStrong dispose d'un systeme de cache très simple et facilement mise en place.

Coté Mysql, il y a la Ezsql qui implémentente un cache, disk_cache.

Vous pouvez trouver des exemples sur ce site

Aour

PS : pear ps toujours disponible

Eroan · 11 Janvier 2009

Pour avoir testé un script de mise en cache très similaire sur mon WWW durant plus d'un an, j'en connais bien les avantages et les limites.

Avantage :

- aucunes requêtes SQL ;
- gain de temps au chargement.

Inconvénients :

- moins de dynamisme ;
- perte de puissance lorsque le nombre de fichiers en cache devient trop important *.

* : mon script de mise en cache enregistrait des fichiers .php de cache dans un répertoire /cache/. Au final, je me retrouvais avec plusieurs dizaines de milliers de fichiers. À l'appel du script, lorsque php recherche si le fichier existe, il ouvre le répertoire et fait un index dessus. Plus le nombre de fichiers en cache est élevé, moins le script est performant.

Au final, j'ai abandonné ce script de mise en cache pour installer e-accelerator, un accélérateur de scripts php côté serveur. Résultat, un gain de performances de l'ordre de 3 ou 4, tout en exécutant à chaque page des dizaines de requêtes mysql...

Ces systèmes de cache ne sont donc pas, de mon point de vue, de bonnes solutions pour les gros sites. Ils sont tout juste bon pour les petits blogs...

Alors pour un forum, ce n'est même pas la peine d'y penser

a+

Bool · 11 Janvier 2009

Hello,

je serais plus réservé sur l'utilisation excessive des caches, j'ai par exemple le serveur d'un client qui rame énormément uniquement à cause du système de cache : il y a des écritures disque en permanence, qui pourrissent complètement les perfs.

Bref déjà il faut distinguer plusieurs choses :
1 - ce qui est mis en cache : des données (par exemple le résultat de requêtes SQL), ou bien le rendu HTML ? Dans le premier cas, c'est souvent réutilisable pour tous les utilisateurs du site, et ça varie pas forcément beaucoup (même pour un forum). Dans le second cas, chaque utilisateur doit avoir son cache, et faut en permanence reconstruire le cache (à chaque message privé par exemple).
2 - où sont stockées les données : en mémoire ? sur le disque ? sur un filer ?? Car s'il s'agit d'un hébergement mutualisé, les écritures disque peuvent être des écritures sur le filer, donc via le réseau, et donc parfois bien plus lentes que le traitement SQL en cas de montée en charge.

Eoran : après il y a aussi des systèmes de cache mieux pensés que d'autres. Par exemple un système de cache qui génère des fichiers ".php" qui seront ensuite chargés à coup d'include() est pour moi une hérésie, le parseur PHP étant lourd, et le cache d'opcode se retrouvant sabordé par ce truc. Un unserialize(file_get_contents()) va finalement beaucoup plus vite, sans empiéter sur le cache d'opcode (uniquement le cache fichier, comme l'autre méthode d'ailleurs).
De la même façons, mettre tous les fichiers de cache dans un même dossier n'est pas bien malin je trouve. On se retrouve à remplir des dossiers et donc à plomber des perfs inutilement, surtout avec un filer derrière.
=> le pire c'est que ces 2 méthodes sont utilisées par phpBB 3...
Dans la même lignée, certains systèmes de cache font un usage intensif des verrous, au moindre pic de trafic, patatra. Un système de cache ne gérant pas les accès simultanés, un comble non ?

Utiliser un système de cache peut être très bénéfique, mais faut pas faire n'importe quoi non plus.

Bacteries · 12 Janvier 2009

Il y a Zend Cache aussi, bien complet, bien documenté.
http://framework.zend.com/manual/fr/zend.cache.html

PHP5 par contre (mais bon on développe plus en 4 hein?)