Utilisation intensive de la mise en cache des pages PHP.

[thierry8]

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

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

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

[thierry8]

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

[thierry8]

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]

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]

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]

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]

ok.

merci beaucoup pour toutes ces informations.

[yakipa]

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]

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]

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]

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]

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