Auteur Sujet: Systeme De Cache Php - Analyse  (Lu 4770 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« le: 30 août 2004 à 09:17:31 »
Bonjour,

Depuis quelques jours, je fais le point sur les systèmes de cache de haut niveau, pour les pages PHP.

Trois variantes semblent revenir régulièrement :

- Le principe de l'écriture d'une page PHP dans un fichier texte ou html, construit générallement lors de la première requête.

- Le codage du fichier demandé (générallement en md5) et sa comparaison avec la version présente dans le cache client, et l'envoi éventuel d'une erreur 304 indiquant que  la page n'a pas été modifiée.

- La gestion de cache mettant en oeuvre les deux points ci-dessus.


Pour le premier cas, un simple script php fait l'affaire. Cela me parait très simple à mettre en oeuvre.

J'ai cependant trouvé un script original, exploitant les erreur 404 (not found) pour générer un fichier html. Ce principe retient tout mon intérêt. En effet, d'une part il est très simple à mettre en place sur un site, sans aucun ajout de code aux pages (il faut cependant que les liens ne pointent plus sur des pages php, mais bien sur des pages html). De plus, il est basé sur le fait que les liens ne comportent plus d'adresses php, mais directement des fichiers html. En terme d'efficacité, c'est top. Non seulement on ne sollicite plus MySQL, mais plus non plus l'interpréteur php.
Par contre, ce script ne gère pas l'envoi d'erreur 304 dans les en-têtes. Mais est-ce bien problématique, puisque logiquement, si une personne a déjà visionné le fichier html une première fois, son navigateur devrait de lui même aller cherche le fichier dans son cache, si celui-ci n'a pas changé (pas sûr sur ce coup là).

Voici l'adresse du script en question : Zend

Malheureusement, ce système de cache a un défaut : la suppression des fichiers caches ne peut se faire que par une intervention volontaire, via par exemple avec l'interface d'administration du site (je ne parle pas de cron). Si cela peut convenir pour la majorité des cas, il peut être utile de donner une durée de vie au fichier cache...


Le deuxième cas, on peut le voir ici, jRcache.

Le troisième cas, vous l'avez à la même adresse (jPcache).

Pour ceux que l'anglais rebute, j'ai trouvé un autre script plus ou moins similaire : HDAcache

J'ai essayé ce dernier et il fonctionne très bien. Envoi de code 304, gestion des durées de vie des fichiers caches...
Mais contrairement au scrit de Zend, il faut ajouter plusieurs lignes de codes dans les fichiers php à "cacher". Son intérêt étant par contre de pouvoir "cacher" des parties de fichiers seulement.


Maintenant, j'en appelle à vos avis, essais sur la chose.
Quel système de cache préférez-vous ? Utilisez-vous ?

Pour ma part, je préfère celui de Zend, qui, comme je l'ai déjà dit, ne sollicite même pas le php pour afficher une page (sauf bien-sûr pour le premier appel d'une page non cachée).

Le débat est ouvert, s'il pouvait nous aider à faire un choix plus juste sur un système simple et efficace.

Merci par avance pour vos réactions.

Hors ligne NICO100

  • Débutant
  • *
  • Messages: 96
    • http://www.bestiaire.org
Systeme De Cache Php - Analyse
« Réponse #1 le: 30 août 2004 à 13:35:27 »
Perso j'utilise Cache_Lite de PEAR, c'est simple, rapide, efficace!
Le jeu du Bestiaire
http://jeu.bestiaire.org/

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« Réponse #2 le: 30 août 2004 à 15:13:48 »
Beaucoup lisent ce post sans indiquer leur solution : serait-ce parce que peu de personnes utilisent un système de cache ?

Pour ce qui est de Cache Lite, voici un lien intéressant : JournalDuNet

Hors ligne Carssou

  • Habitué
  • **
  • Messages: 247
Systeme De Cache Php - Analyse
« Réponse #3 le: 31 août 2004 à 11:53:56 »
J'ai lu rapidement l'article du JDN et je vais me laisser tenter par ce script :)
Je pense que le cache ne peut être que bénéfique et recommandé sur des sites hébergés sur un serveur mutualisé.

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Systeme De Cache Php - Analyse
« Réponse #4 le: 31 août 2004 à 18:38:24 »
Sur la demande de Yannick, voici mon opinion...

A chaque probleme correspond un outil. Ce qui peut etre une solution optimale pour un cas particulier peut-etre catastrophique dans une autre configuration, ou simplement d'un autre point de vue. Par exemple, si vous me parlez de gains http, je vous parlerai de pertes CPU, RAM, de complexites, voire plusieures contre-performances a la fois :)

Il faut particulierement faire attention aux couts de chaque solution -
couts de mise en oeuvre, couts de maintenance ( + evolutivite), et couts de fonctionnement - et mettre cela en vis-a-vis des gains apportes.

Il existe des sytemes de cache/optimisation serveur (SGBD, Zend, etc.) Pour les pauvres utilisateurs (hebergement mutualise) :

* Un cache par fichier impose de gerer les fichiers : supprimer periodiquement les caches perimes, comparer les dates, parcourir l'entierete d'un ou plusieurs repertoires de cache (voire des repertoires recursifs), etc. A cela il faut tenir compte du probleme d'acces concurentiel aux fichiers (ex: plusieures personnes en meme temps veulent ecrire le meme fichier, ecrire/lire/supprimer le meme fichier). Sur un serveur mutualise, ce systeme est rapidement penalisant.

* Pour un cache par base de donnees, le probleme d'acces concurrentiel est negligeable, reste relatifs aux traitements SQL.

* Une solution par etags ? Cela impose un traitement supplementaire systematique pour toutes les pages. Quelles soient envoyees ou non, que le navigateur gere les etags ou non. En terme de cout, si les precedents systemes pouvaient etre compares a une "redevance", ce systeme correspondrait alors a une sorte de taxe.


Quelles sont les donnees a mettre en cache ? Dans quel(s) but(s) ? Dans quels circonstances (nbr de requetes), etc. Est-ce que cela vaudrait la peine, par exemple de mettre en cache (fichier/sql) des pages de forums Peut-etre si le taux de lecture est largement plus eleve que celui d'ecriture, et si les utilisateurs consultent globalement les memes pages dans les memes conditions (meme rendu http). Dans d'autres conditions : un tel systeme de cache sera plus nefaste qu'autre chose (surcharge CPU). Des etags? C'est a dire, en dehors de toute la memoire que pourrait deja consommer le script (libraires GD, imagick, variables non supprimees, fuites de memoire, etc.), manipuler l'entierete de la sortie HTML dans un buffer et appliquer un traitement aleatoire a ce buffer... Ce systeme ne fonctionne reellement que lorsqu'un utilisateur passe son temps a appuyer sur sa touche <F5>. Dans les autres cas, il faut tenir compte des caracteristiques de chaque navigateur. Sans oublier que cette methode si elle soulage de temps en temps le transfert http, entraine d'office et systematiquement une charge serveur supplementaire.

La situation serait tout autre pour un site "carte de visite". Ou une "statification" definitive, ou du moins a long terme, peut-etre envisagee. Pour un site interactif (blogs, forums, webmail, livre d'or, annuaire, etc.), une solution envisageable serait de realiser un cache par blocs de donnees partages (entete, pied de page, etc...). Specialement si le degre d'interactivite - de personnalisation- est eleve.


La vrai question reste dans quel but vouloir utiliser un cache ?
- Pour reduire les traitements SQL ? Optimiser sa conception SQL EST la meilleure solution. Si cela ne sufit pas, il faut penser a changer de serveur SQL (postgreSQL/Oracle).
- Pour optimiser les traitements php ? Optimiser le code php EST la meilleure solution.
- Pour optimiser les transfert de bande passante ? Optimiser ses ressources (images/CSS/HTML/etc) EST la solution. Et si cela ne suffit pas, il est plus que temps d'envisager une formule d'hebergement plus confortable.


En conclusion : hors quelques cas precis (assimilables a la compilation d'un programme), l'utilisation d'un systeme de cache, est une pseudo-solution que l'on applique rapidement comme un patch, non pas pour resoudre un probleme, mais pour le repousser.

Les meilleures optimisations sont celles qui sont realisees des la conception d'une application. Si l'ajout d'un systeme de cache est essentiel pour une application, alors - c'est une Lapalissade : - c'est l'utilisation de cette application qui est le probleme Mauvaise conception ou mauvais usage. A l'inverse, si l'ajout d'un systeme de cache n'est pas essentiel, alors il existe certainement des choses plus importantes auxquelles consacrer son temps.
« Modifié: 31 août 2004 à 19:43:11 par Dash »

Hors ligne zespri

  • Habitué
  • **
  • Messages: 202
Systeme De Cache Php - Analyse
« Réponse #5 le: 31 août 2004 à 20:25:26 »
assez d'accord avec dash, néanmoins je trouve qu'il y a des utilisations du cache qui peuvent etre interessant notament pour une page d'accueil qui serait variable d'un jour à l'autre, mais fixe pour la journée, dans ce cas ça me parait interessant....
mais c'est vrai que les applications restent limitées de mon point de vue

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« Réponse #6 le: 31 août 2004 à 22:02:15 »
Tout d'abord, merci, Dash pour ton intervention (demandée en perso).

Cependant, si, comme tu le montres à merveille, le cache n'est pas la solution à tout, il semble quand même qu'utilisé de manière inteligente, il accélère d'une part l'affichage des pages web, et soulage en partie le serveur http, et à 100% le serveur sql, qui pourra ne pas être sollicité du tout pour l'affichage d'une page cachée.

Pour ma part, je dois souvent réaliser une page écran pouvant être mise à jour par le client. Il peut s'agir d'une simple page de saisie libre. Je placais avant le contenu dans un fichier texte, pour éviter un appel au serveur sql, d'autant qu'il peut y avoir une fréquence de mise à jour au mieux hebdomadaire, voir mensuelle !

Cacher une telle page est essentiel. Surtout si on s'adresse directement à un fichier html : plus de php, plus de sql, le top.

Autre exemple, une page d'accueil récupère les titres "chauds" d'un agenda. Est-il utile de solliciter le serveur sql dans ce cas, non évidemment. Un cache journalier est souvent suffisant, puisque la requête sql correspondante à souvent la précison d'une journée : jour passé, on supprime ou grise.

Sur un site, il y a rarement que des pages type forum.  Souvent, un site est basé sur la publication d'un article, qu'il n'est pas justifié d'aller chercher dans MySQL à chaque affichage, à moins bien-sur d'un site comportant dix milliers d'articles. Dans ce cas, ne cacher que les plus récents, ceux pouvant être les plus affichés.

En fait, à mon sens, tout dépend presque exclusivement des fréquences de mises à jour. Idéallement, le php ne devrait être utilisé que pour créer une page dynamique. Ce qui veut bien dire ce que ca veut dire : un calcul avec un paramètre différent à chaque fois, c'est dynamique. Toute page ne changeant pas fréquemment devrait être cachée. Et évidemment, plus le site reçoit de visiteurs, et plus le cache se justifie (on imagine pas un cache pour 3 visites/jour, la création des fichiers caches serait trop fréquente par rapport à celle de la lecture des fichiés cachés).

Dès aujourd'hui, je vais utiliser un système basé sur la solution proposée sur le site de Zend, qui permet de ne pas s'adresser non plus à l'interpréteur php. Un must. Un site caché peut monter davantage en charge qu'un site non caché.




 

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Systeme De Cache Php - Analyse
« Réponse #7 le: 31 août 2004 à 23:50:07 »
Quelques applications pour un cache :

- sites dynamiques :
Certains forums, CMS et autres applications (ex: WysiwygPro) proposent une gestion de cache par niveau, voire par morceaux.
Par niveau : le moteur de template de phpbb (que l'on peut facilement recuperer pour d'autres sites internet) interprete des gabarits pour un code php. une fois ce code mis en cache, il n'est plus necessaire de "compiler" a nouveaux les gabarits. L'utilisation directe de ce"code compile", permet de soulager le serveur, et d'acceleres les traitements.
Par morceaux : des elements communs frequement utilises identiquement peuvent facilement se mettre en cache : calendrier (a priori l'affichage d'un calendrier reste identique quotidiennement), page d'accueil, menus de navigation, pied de page... Il suffit ensuite, d'assembler les morceaux et de completer.

Citer
Toute page ne changeant pas fréquemment devrait être cachée. Et évidemment, plus le site reçoit de visiteurs, et plus le cache se justifie (on imagine pas un cache pour 3 visites/jour, la création des fichiers caches serait trop fréquente par rapport à celle de la lecture des fichiés cachés).
Pourquoi ? Les economies de 2 ou 3 requetes SQL, de quelques centiemes de seconde de traitement php, de quelques pourcents de charge, sont-elles vraiment indispensables ? Si vraiment le gain de temps, et la charge serveur vous interessent, alors pour obtenir des gains reellement notables vous auriez davantage interet a investir plutot dans d'autres applications mieux concues, quelques bouquins qui vous permettent de mieux concevoir vos applications ou meme investir quelques euro supplementaires dans un serveur dedie avec postgreSQL et des solutions serveurs (Zend Cache, Zend Optimiser, etc.) !


Citer
En fait, à mon sens, tout dépend presque exclusivement des fréquences de mises à jour. Idéallement, le php ne devrait être utilisé que pour créer une page dynamique. Ce qui veut bien dire ce que ca veut dire : un calcul avec un paramètre différent à chaque fois, c'est dynamique.
Le probleme n'est pas la. Est-ce au responsable d'un site a se dire comment devrait etre utilise un langage comme php ou au concepteur d'une application a y reflechir ? Est-ce au responsable d'un site a aller tripatouiller le code source pour y apporter des pseudo-solutions ou au concepteur a etablir un cahier de charges precis ou l'optimisation est prise en compte en amont ? Vous amusez-vous a bibouiller votre aspirateur pour qu'il aspire mieux, plus vite et en en consommant moins ? Ou preferez-vous tout simplement changer d'aspirateur une fois qu'il vous semble trop poussif ? Prefereriez-vous acheter une vieille voiture hors d'age avec un moteur trafique ou une voiture concue expressement pour les performances ? Vous pouver vous amuser a bidouiller votre petit site personnel pour y caser a tout prix un systeme de cache aux hypothetiques resultats, mais s'il s'agit d'un site associatif, professionnel, 'corporate' ou institutionnel, ce genre de bricolage de quat'sous, est vite a proscrire. Ce qui se concoit bien...

- syndication (JS/PHP/txt/xml/rdf/rss/etc.) :
Vous recuperez des donnes d'un site externe (ou d'une autre partie de votre propre site). Utilisez un cache local. Cela permet non seulement de soulager le serveur externe (SQL et autres langages) mais cela vous permet d'accelerer votre site (les appels externes sont souvent longs), et cas d'inaccessibilite de celui-ci, cela n'a pas de repercussion directe sur votre propre site. Non seulement vos utilisateurs vous en seront reconnaissant, mais le responsable et les utilisateurs du serveur distant egalement. C'est la a mon avis la seule occasion pertinente, et rarement exploitee, pour se risquer a greffer un systeme de cache non-natif a une application internet.

Le reste, fondamentalement, n'est pas du developpement applicatif, c'est du bricolage du dimanche.

:)
« Modifié: 01 septembre 2004 à 00:09:51 par Dash »

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« Réponse #8 le: 01 septembre 2004 à 09:29:56 »
Moi je vois la chose autrement. Je me fais maintenant une obligation de cacher les types de pages décrites plus haut, que je considère désormais non pas comme du bricolage du dimanche, mais bien comme faisant partie intégrante de la programmation php...

Nombreux sont les tests effectués sur des pages cachées (y compris sur des pages ne contenants que de simples includes, mais qui génèrent de ce fait autant d'appel au système de fichier. Attention, je ne fais pas une généralité, et comme dis par Dash, chaque cas mérite d'être étudié) et qui montrent bien l'intérêt d'une telle solution, surtout sur du mutualisé où les caches de bas niveaux ne sont pas applicables.

A chacun sa vision des choses  ;)

Quelques liens :

jdnet
Zend

Tests des caches et mise en évidence de l'efficacité des caches de hauts niveaux dans ce livre

Enfin, notons au passage que de plus en plus d'applications php utilisent maintenant un système de cache de haut niveau.

EDIT :

Citer
Le probleme n'est pas la. Est-ce au responsable d'un site a se dire comment devrait etre utilise un langage comme php ou au concepteur d'une application a y reflechir ? Est-ce au responsable d'un site a aller tripatouiller le code source pour y apporter des pseudo-solutions ou au concepteur a etablir un cahier de charges precis ou l'optimisation est prise en compte en amont ? Vous amusez-vous a bibouiller votre aspirateur pour qu'il aspire mieux, plus vite et en en consommant moins ?

Comprend pas. Quel est le rapport ?

Citer
un systeme de cache aux hypothetiques resultats
Ah ? Ils sont souvent aussi efficaces que les caches de bas niveaux (voir plus, même si la comparaison est délicate car ne fonctionnant pas sur le même principe). Ils permettent aussi, dans certains cas, de rendre la page accessible même sir le serveur sql est out...

Citer
Pourquoi ? Les economies de 2 ou 3 requetes SQL, de quelques centiemes de seconde de traitement php, de quelques pourcents de charge, sont-elles vraiment indispensables ?

Ce la dépend de la requête. Et puis sur un mutualisé, les 2 à 3 requêtes de tous, ca commence à se connaitre. Et puis, un système de cache n'est pas lourd a mettre en place, c'est hyper rapide, pourquoi s'en priver.
« Modifié: 01 septembre 2004 à 09:36:34 par Yannick »

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Systeme De Cache Php - Analyse
« Réponse #9 le: 01 septembre 2004 à 12:01:46 »
En effet, pourquoi s'en priver...
Si les systemes de cache etaient si essentiels, pourquoi ne sont-ils pas prevus systematiquement dans les applications php ? Sur un hebergeur mutualise les resultats sont mutualises. Si un voisin charge constamment les seveurs, cela s'en ressent partout. Si sur un mutualise, les 2 a 3 requetes de plus posent reellement probleme, pourquoi ne pas generaliser l'usage d'une solution mutualisee : postgreSQL avec ses performances meilleures que mySQL, Oracle, mySQL 4 et son systeme de cache, Zend Optimizer, Cache serveurs, etc. Si les systeme de cache etaient si essentiels, les hebegeurs devraient dire : "utilisez des caches!" en complement (ou au lieu) de "optimisez vos scripts".


Prennons un cas concret : ce forum-ci utilise un systeme de cache SQL.
Comme j'ai deja eu l'occasion de l'expliquer :
- l'objectif n'etait PAS ici de generer des pages plus rapidement (IPB est a la base suffisament correctement concu). Au contraire, statistiquement ces-forums ci ont besoin de plus de CPU et plus de temps pour generer les pages que vous lisez.
- L'objectif n'etait PAS ici d'utiliser un systeme de cache pour le plaisir d'utiliser un systeme de cache. Le rapport lecture/ecriture seraient ici largement favorable pour utiliser un cache de pages. Mais si un tel cache n'est pas utilise c'est tout simplement parce que ce n'est pas necessaire.  

Tout part d'une analyse (benchmarking /profiling). Ou sont situes les goulots d'etranglements d'un script ? S'agit-il d'un mauvais code php qu'il faut re-ecrire ? S'agit-il d'une contraintes materielles auxquelles il faut trouver une alternative ? etc.

Pour l'avoir concu, je peux affirmer que le systeme mis en place, est lourd, qu'il fait appel a davantage de ressources CPU et davantage de ressources memoires. Il induit un temps de generation de page souvent plus long. Pire, le code est loin d'etre completement optimise.


Quel est l'interet alors ? le principal goulot d'etrangelement, celui qui cause regulierement des problemes, reside dans le traitement SQL (erreurs de connexions simultanees, lenteur, etc). Ouvrir, executer les requetes et fermer aussitot une connexion permet de 'soulager' le serveur SQL, mais induit des temps de traitement plus longs (l'ideal reste de reformuler la conception des forums ou choisir des forums plus adapter a l'environnement phpnet). La gestion de cache SQL implique ici une gestion de fichiers de cache. Sauf exception les manipulations via le serveur de fichiers sont plus rapides que via le serveur SQL. Le cache permet donc des gains non negligeable de ce point de vue. Cependant, la gestion de ces fichiers de cache (suppression, expiration, reconstruction, statification, gestion des liaison entres tables/caches, etc.) est, dans certaines, circonstances un cauchemard. Dans tout les cas cela entraine une charge CPU qui est tres loin d'etre negligeable. Sans evoquer les complexites de mise en oeuvre de parametrage et d'adaptation aux modifications personnelles, si du point de vue de l'utilisateur les forums peuvent semblent plus rapide, et provoquer moins d'erreur, du point de vue du serveur par contre, c'est loin d'etre une solution gratuite. Et donc, si on peut s'en passer, autant s'en passer :)


Lorsqu'un utilisateur me demande si ce systeme de cache SQL lui permettrait de faire tourner IPB sur un hebergeur comme phpnet, j'ai plutot tendance a donner le conseil suivant - et non pas seulement parce eviter d'assurer un quelconque support : si les restrictions de votre hebergeur vous genent, prennez plutot un autre hebergeur plus adapte a vos besoins ou une application plus adaptee a votre hebergeur.

Citer
Enfin, notons au passage que de plus en plus d'applications php utilisent maintenant un système de cache de haut niveau.
Effectivement, une application qui a ete concue (cad cahier de charges, etudes, etc.) avec un systeme de cache natif aura toujours une meilleure coherence (et des performances globables) qu'une application sur laquelle on colle un systeme de cache recupere on ne sait ou et/ou developpe durant un week-end pluvieux.

A propos de conception, IPB 2.0 utilise de maniere interessante des specificites de php pour optimiser son fonctionnement. la fonction php 'register_shutdown_function' a un effet comparable au destructeur d'une classe (php5 par exemple ou c++/java et autres langages objets). Differer des traitements a la cloture d'un processus demande de revoir l'entierete de la conception d'une application mais les gains sont globalement tres appreciables. En guise de conclusion : une bonne conception permet aux developpeurs d'identifier les problemes, d'utiliser les bons outils pour les resoudre, et doit egalement permettre aux utilisateurs de ne pas avoir a bidouiller le code source pour y integrer ulterieurement des systeme de cache aux gains hypothetiques :)

-----
nota : le mot 'hypothetique' est utilise a dessein, a defaut de chiffres et graphiques a l'appui (PHP/CPU/RAM/HTTP) pour demontrer que l'utilisation de cache(s) est
1°/ raisonnablement necessaire;
2°/ qu'il s'agit de la meilleure solution pour resoudre un probleme reel;
3°/ que les gains apportes sont significatifs (PHP/CPU/RAM/HTTP/...) sur les differents serveurs (fichiers/SQL/...), ponctuellement et sur le moyen/long terme;
« Modifié: 01 septembre 2004 à 14:03:35 par Dash »

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« Réponse #10 le: 01 septembre 2004 à 14:07:25 »
Le débat m'achappe un peu.

Tout d'abord, pour reprendre à zéro, je t'ai contacté en perso car ton avis m'intéraissais, car j'avais le souvenir d'un intervenant (mais est-ce bien le même Dash) qui prêchait l'utilisation d'un cache.

Pour ce qui est des bons et mauvais scripts, c'est au autre débat. Là n'est pas la question. Un cache peut s'appliquer à un bon ou mauvais script, le mauvais restera mauvais et voilà, encore une fois, là n'est pas la question.

Pour continuer, et après de longues recherches sur le sujet, toi seul a un avis si négatif sur la chose. Je te retourne ta question : prouve moi, chiffre à l'appui, qu'un système de cache n'apporte que peu de chose et on en reparlera. Tous les tests effectués que j'ai pu lire sont unanimes. On peut passer d'une limitation de 15 requêtes de pages/secon à plus de 100 sans problème, rien que par l'emploi d'un cache.

Maintenant, il faut bien savoir de quoi on parle quand on parle de cache, et à quoi on l'applique. Je suis d'accord avec toi sur le fait qu'il n'est pas nécessaire dans toutes les situations. Mais, et contrairement à toi à priori, je redis haut et fort qu'une page regénérée que quotidiennement, ou mensuellement -doit- être cachée.  Ne serait-ce qu'avec 10 visiteurs/jours, et même si le système de mise en cache demande un peu de ressource (souvent uniquement un peu de code php, faut pas exagérer), s'il doit créer le cache une fois par jour,  c'est tout gagnant pour les 10 visiteurs qui ne solliciteront pas le serveur sql.

Pas plus que l'interpréteur php, si le cache est basé sur la construction de fichier html.

En fait, je ne comprends pas la généralisation que tu prêches, alors que 90% des sites dit "dynamiques" courants, ne contienne qu'une infime partie de code mis à jour chaque seconde.


Et souvent, l'effacement du cache et sa reconstitution peut être faite par l'interface d'administration.

A toi de nous expliquer comment un <a href="monfichier.html'></a> est plus gourmand en ressource qu'un <a href="monfichier.php"></a>, surtout si le php en question interroge un serveur sql.

Si on est d'accord pour dire qu'un système de cache ne fait pas tout, reconnait au moins que cela dépend des types de pages (et donc de scripts, de fréquence de mise à jour...)

Enfin, avec un dédié aux performances modestes, programmer de la sorte permet de placer un peu plus de sites, tout en augmentant le temps de réactivité du serveur quant à la constitution des pages.

Je remarque aussi que tu fais souvent référence aux forums, alors que dès mes premiers posts, je les écarte au bénéfice des pages "semi-dynamiques".

Citer
Prouvez-moi avec chiffres et graphiques a l'appui que les gains sont non seulement significatifs (PHP/CPU/RAM) sur les differents serveurs (fichiers/SQL) mais qu'en plus un systeme de cache est la meilleure solution qui s'impose pour resoudre un probleme concret.

Je n'ai jamais parlé de résoudre un problème. Juste de ne pas solliciter un serveur pour rien. Pour ce qui est des chiffres (et mêmes des graphiques), vous les avez dans la bible du php, de manière très détaillée. On retrouve d'autres tests de ce genre sur le web.

Citer
Si les systemes de cache etaient si essentiels, pourquoi ne sont-ils pas prevus systematiquement dans les applications php ?
Ils le sont de plus en plus, toi même l'a dit.


Citer
Si sur un mutualise, les 2 a 3 requetes de plus posent reellement probleme, pourquoi ne pas generaliser l'usage d'une solution mutualisee : postgreSQL avec ses performances meilleures que mySQL, Oracle, mySQL 4 et son systeme de cache, Zend Optimizer, Cache serveurs, etc.
Tu sais comme moi que les sytèmes de cache de bas niveaux peuvent être contre-productifs sur du mutualisé. Quant au reste, là encore c'est un autre débat.

Citer
n guise de conclusion : une bonne conception permet aux developpeurs d'identifier les problemes, d'utiliser les bons outils pour les resoudre, et doit egalement permettre aux utilisateurs de ne pas avoir a bidouiller le code source pour y integrer ulterieurement des systeme de cache aux gains hypothetiques

Encore une fois, c'est deux choses différentes. Une bonne conception peut tout aussi tirer avantage d'un cache. Quant aux gains "hypothetiques", je te renvoie aux tests existants (cf ci-dessus).

Ma conclusion, c'est qu'il est inutile de demander plusieurs fois de suite la construction d'une page, si son contenu ne change pas toutes les heures ou secondes. Cela sonne à mes oreille comme une évidence. Et contrairement à ce que tu dis, je ne considère pas cela comme du bricolage, mais bien comme une manière de concevoir la prog php et l'application qui en résulte.

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Systeme De Cache Php - Analyse
« Réponse #11 le: 01 septembre 2004 à 15:30:01 »
De memoire, il existe des sites (comme ipbr-fr.com) ou vous pourrez trouver de nombreux retours d'experience de personnes utilisant ou ayant utilise un cache SQL et l'ayant desactive. Parce que cela ne faisait que deplacer le probleme (avec phpnet par exemple), ne reduisait les problemes mais ne les resolvait pas, etc. En cherchant, Vous pourrez egalement trouver des temoignages de personnes s'etant fait suspendre leurs hebergements en ayant pourtant utilise un cache SQL (moins de traitement SQL, certes, mais surcharge CPU). Je vous laisse chercher ces informations :)

Et puisque vous avez sous les yeux une application utilisiant un systeme de cache, demandez a l'occasion a maverick ou thibaud les chiffres et autres graphiques concernant ces forums-ci. Cela confirmera que si le seveur SQL est legerement soulage, c'est au prix d'une charge supplementaire constante en terme de CPU et de RAM. Demandez egalement l'avis aux responsables d'hebergeurs (phpnet, et autres) ce qu'ils pensent des systemes de cache,dans quels cas cela est pertinent d'apres leurs donnees et dans quel cas cela releve du superflu. Ils sont particulierement bien place pour donner un avis pertinent sur la question :)

Je ne suis pas contre l'utilisation de caches. Loin de la.

Simplement il semble en effet que l'on ne parle pas de la meme chose.
il n'y a aucune generalite possible, nous sommes d'accord.
Il y a des differences d'interactivite.
Il y a des differences entre un petit site, et un site plus complexe.
Il y a des differences entre une faiblement frequentation et activite importante.
Il y a des differences entre cache SQL, cache http, et autres formes de cache.
Il y a des sites qui fonctionne convenablement, tres largement en dessous des seuils critiques, et donc naturellement sans besoin de cache.

Il y a les caches qui font partie integrante d'une fonctionnement, du cahier de charge et de la nature meme de l'application. L'application a ete concu AVEC un ou plusieurs systemes de cache. Il y a coherence tant dans la conception que dans la maintenance et les evolutions possibles.

Face a cela, il y a les caches que l'on installe parce qu'une application a ete mal concue, mal developpee,
parce qu'elle n'est pas adaptee a un environnement (utilisateur/technique) ou simplement parce qu'un webmaster se dit "ce n'est pas absolument necessaire, mais pourquoi ne pas essayer".


Il faut egalement faire la difference une application que vous recuperez/utilisez et une application que vous developpez. Si vous concevez et developpez votre propre application, pour bien faire, idealement les systemes de caches doivent s'integrer dans une strategie globable. Si vous utilisez une application, modifiez le fonctionnement d'une application existante e se fait pas sans une dose de risque, et ne simplifie habituellement pas la maintenance ou la mise a jour de cette application. Dans ce cas (utilisation de scripts non prevu dans la conception originelle), je ne vois pas de raison a l'insertion ulterieure de systemes de cache, quels qu'ils soient. Il y a suffisament de choix d'applications et d'hebergements pour trouver ce qui convient le mieux.

Pour le reste, lorsqu'il s'agit de developper soi-meme ses scripts, a chacun de prendre ses responsabilites et voir si parmi toutes les solutions possibles, raisonnables et envisageables, les systemes de cache sont ou non les solutions optimales (en fonction du probleme et du choix de la solution), qui correspondent a ses besoins, a ses specifications (hebergeur et autre contraintes),et a ses connaissances (maintenance/evolutivite) ponctuellement et sur un plus long terme.

L'efficacite d'un cache dependant en grande partie de votre site, et des contraintes et des possibilites materielles mis a votre disposition par votre hebergeur, je vous invite a poursuivre cette discussion - qu'il s'agisse du choix d'un systeme de cache, de son parametrage ou du developpement d'un futur cache- avec le support phpnet. Au besoin ils pourront vous fournir des chiffres et des graphiques pertinents pour alimenter votre discussion/reflexion :)
« Modifié: 01 septembre 2004 à 15:43:27 par Dash »

Hors ligne maverick78

  • VIP
  • *****
  • Messages: 2 601
    • http://www.clan-ck.com
Systeme De Cache Php - Analyse
« Réponse #12 le: 01 septembre 2004 à 16:15:30 »
je confirme les dires de dash, un systeme de cache ne fait que repousser l'écheance et jai deja vu des forums coupés alors qu'ils avaient le systeme de cache...
cependant je n'ai pas de graphs particuliers a afficher pour confirmer les dires :D

J'ai effectivement remarqué que bien que le temps sql diminue le temps global reste le meme si ce n'est plus elevé (ce qui avait a l'epoque sucité une reaction de sasayaki concernant l'utilité)
La force est dans la céréale
Clan cereal-killer : http://www.clan-ck.com

Ne te demande pas ce que ton pays peut faire pour toi mais plutôt ce que tu peux faire pour ton pays...(JF Kennedy)

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Systeme De Cache Php - Analyse
« Réponse #13 le: 01 septembre 2004 à 16:21:17 »
C'est quand même assez incroyable. Je répette une fois de plus : je ne parle pas de forums, mais de pages semi-dynamiques mises à jour  au mieux une fois par jour.

Il faut l'écrire en quelle langue ?

Et encore une fois, dans un tel cas, (et c'est le plus fréquent, peu de sites ne contiennent QUE des forum ou pages mises à jour à la seconde !) le cache est bénéfique.

Des chiffres ? En voici dans ce pdf.  

Hors ligne Philemon

  • Débutant
  • *
  • Messages: 52
Systeme De Cache Php - Analyse
« Réponse #14 le: 02 septembre 2004 à 10:38:23 »
Ce sujet est très intéressant. Jusqu'à aujourd'hui, j'étais persuadé de l'utilité d'un système de cache. Des tests rapides me permettent d'en douter. Merci pour l'information.

J'aimerai bien comprendre pourquoi un système de cache n'est pas plus efficace.  Depuis un moment, je soupçonne les accès fichiers (écriture, lock, statistiques,...) d'être très lourds. Est-ce que quelqu'un peut le confirmer ?

Je suppose maintenant qu'un cache n'est pas nécessaire en dessous d'une taille critique, en nombre de requêtes et en nombre de lignes de codes.
Pour se faire une religion : il est toujours possible de mettre en place un système de cache et de vérifier, par test, page par page de son utilité.

Je suppose aussi qu'il est inutile de mettre en place un système de cache à plusieurs niveaux. Il faudrait plutôt chercher à mettre en cache toute une page pour que ça soit rentable.

En tout cas, je vois un cas ou le cache est indispensable.  C'est dans le cas d'une galerie d'images avec des vignettes. Il est indispensable de ne pas recalculer les vignettes à chaque fois.

On a vu qu'il y a aussi des cas ou c'est contre-productif. Par exemple : pour un forum. Il y a sûrement d'autres cas entre les deux ... Comme Yannick, je me pose la question.


Citer
Le reste, fondamentalement, n'est pas du développement applicatif, c'est du bricolage du dimanche.

Je pense qu'il ne faut pas mépriser le "bricolage du dimanche". J'imagine que beaucoup de sites hébergés ici sont le fait d'amateurs, dans tous les sens du terme.

On peut difficilement comparer le montage d'un petit site Web avec le développement d'une grosse application.  Un site Web peut être tout simplement un plaisir, une activité de loisir qui ne nécessite pas forcément la mise en oeuvre d'une méthode d'analyse complexe. Même si, bien sûr, je conseille à tout le monde un minimum de préparation avant de coder.

Beaucoup d'entre nous font ici leur premier pas en PHP avant , peut être, d'aller plus loin. Et j'ai beaucoup d'estime pour ceux qui, mutualistes consciencieux, occupent leur temps libre à optimiser un site préexistant. D'ailleurs, je me demande si à côté de la charte qui interdits les comportements abusifs, il ne pourrait pas y avoir une charte du bon mutualiste qui encouragerait les comportements loyaux vis-à-vis de la communauté.
« Modifié: 02 septembre 2004 à 10:39:33 par Philemon »