Appels à une base de données (MySQL) dont les entrées ne changent pas
tous les jours (certaines pas plus d'une fois par mois) mais sont
appellées plusieurs centaines de fois par jour...
Comment mettre en place un système de cache en partant de rien, c'est à
dire en débutant sur le sujet et éventuellement sans outil spécifique ?
Je veux dire par là que l'idéal serait de pouvoir coder la solution
plutôt que d'incorporer un produit/script existant, si c'est possible.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John GALLET
Bonjour,
Voilà encore une fois tout est dans le sujet : Oui mais non. Est-ce la solution la plus adaptée ?
Appels à une base de données (MySQL) dont les entrées ne changent pas tous les jours (certaines pas plus d'une fois par mois) mais sont appellées plusieurs centaines de fois par jour...
Donc un cache SGBD pourrait faire l'affaire aussi. Les diverses couches d'abstraction de SGBD disponibles comme par exemple ADOdb disposent nativement de ce type de cache. L'avantage est que c'est totalement transparent dans les couches du haut, la seule contrainte (qui n'en est pas vraiment une) est d'utiliser la couche d'abstraction en question.
Comment mettre en place un système de cache en partant de rien, c'est à dire en débutant sur le sujet et éventuellement sans outil spécifique ? Je veux dire par là que l'idéal serait de pouvoir coder la solution plutôt que d'incorporer un produit/script existant, si c'est possible.
Autant je soulignais qu'il faut, quand on utilise un logiciel complet, bien se méfier de ses failles, autant quand on a besoin d'une librairie déjà développée par d'autres, on peut essayer de l'utiliser directement. En se méfiant de ses failles également, il n'y a qu'à voir http://isc.sans.org/diary.php?storyid3 par exemple, dommage pour les utilisateurs de cette belle classe PEAR, mais on ne peut pas non plus tout disséquer ligne par ligne (même si c'est du vrai hacking et très instructif).
Maintenant sur le fond, en prenant un cas *simple voir simpliste* une première approche peut consister à :
- supprimer sur le file system tous les fichiers du répertoire cache datant de plus de xx minutes/heures etc... Ceci peut potentiellement avoir lieu par crontab, ou par l'activité sur le site, cf http://faqfclphp.free.fr/ chapitre crontab.
- prendre le md5 (ou toute autre signature simple) de la query string (i.e. tous les arguments reçus), vérifier si un fichier HTML de ce nom existe dans le répertoire cache (ne pas oublier l'appel à clearstatcache()...). Si oui, le renvoyer. Si non, générer le html correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Ceci est une approche bourrin qui ne marchera pas sur des morceaux, i.e. on cache toute la page, pas des bouts. Certains systèmes de templates gèrent des caches HTML partiels.
Il y a probablement moyen de faire beaucoup plus fin/intelligent/etc... mais cette première approche donnera un compromis correct simplicité de développement / résultat.
HTH, JG -- Les autres, c'est l'enfer.
Bonjour,
Voilà encore une fois tout est dans le sujet :
Oui mais non. Est-ce la solution la plus adaptée ?
Appels à une base de données (MySQL) dont les entrées ne changent pas
tous les jours (certaines pas plus d'une fois par mois) mais sont
appellées plusieurs centaines de fois par jour...
Donc un cache SGBD pourrait faire l'affaire aussi. Les diverses couches
d'abstraction de SGBD disponibles comme par exemple ADOdb disposent
nativement de ce type de cache. L'avantage est que c'est totalement
transparent dans les couches du haut, la seule contrainte (qui n'en est
pas vraiment une) est d'utiliser la couche d'abstraction en question.
Comment mettre en place un système de cache en partant de rien, c'est à
dire en débutant sur le sujet et éventuellement sans outil spécifique ?
Je veux dire par là que l'idéal serait de pouvoir coder la solution
plutôt que d'incorporer un produit/script existant, si c'est possible.
Autant je soulignais qu'il faut, quand on utilise un logiciel complet,
bien se méfier de ses failles, autant quand on a besoin d'une librairie
déjà développée par d'autres, on peut essayer de l'utiliser directement.
En se méfiant de ses failles également, il n'y a qu'à voir
http://isc.sans.org/diary.php?storyid3 par exemple, dommage pour les
utilisateurs de cette belle classe PEAR, mais on ne peut pas non plus
tout disséquer ligne par ligne (même si c'est du vrai hacking et très
instructif).
Maintenant sur le fond, en prenant un cas *simple voir simpliste* une
première approche peut consister à :
- supprimer sur le file system tous les fichiers du répertoire cache
datant de plus de xx minutes/heures etc... Ceci peut potentiellement
avoir lieu par crontab, ou par l'activité sur le site, cf
http://faqfclphp.free.fr/ chapitre crontab.
- prendre le md5 (ou toute autre signature simple) de la query string
(i.e. tous les arguments reçus), vérifier si un fichier HTML de ce nom
existe dans le répertoire cache (ne pas oublier l'appel à
clearstatcache()...). Si oui, le renvoyer. Si non, générer le html
correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Ceci est une approche bourrin qui ne marchera pas sur des morceaux, i.e.
on cache toute la page, pas des bouts. Certains systèmes de templates
gèrent des caches HTML partiels.
Il y a probablement moyen de faire beaucoup plus fin/intelligent/etc...
mais cette première approche donnera un compromis correct simplicité de
développement / résultat.
Voilà encore une fois tout est dans le sujet : Oui mais non. Est-ce la solution la plus adaptée ?
Appels à une base de données (MySQL) dont les entrées ne changent pas tous les jours (certaines pas plus d'une fois par mois) mais sont appellées plusieurs centaines de fois par jour...
Donc un cache SGBD pourrait faire l'affaire aussi. Les diverses couches d'abstraction de SGBD disponibles comme par exemple ADOdb disposent nativement de ce type de cache. L'avantage est que c'est totalement transparent dans les couches du haut, la seule contrainte (qui n'en est pas vraiment une) est d'utiliser la couche d'abstraction en question.
Comment mettre en place un système de cache en partant de rien, c'est à dire en débutant sur le sujet et éventuellement sans outil spécifique ? Je veux dire par là que l'idéal serait de pouvoir coder la solution plutôt que d'incorporer un produit/script existant, si c'est possible.
Autant je soulignais qu'il faut, quand on utilise un logiciel complet, bien se méfier de ses failles, autant quand on a besoin d'une librairie déjà développée par d'autres, on peut essayer de l'utiliser directement. En se méfiant de ses failles également, il n'y a qu'à voir http://isc.sans.org/diary.php?storyid3 par exemple, dommage pour les utilisateurs de cette belle classe PEAR, mais on ne peut pas non plus tout disséquer ligne par ligne (même si c'est du vrai hacking et très instructif).
Maintenant sur le fond, en prenant un cas *simple voir simpliste* une première approche peut consister à :
- supprimer sur le file system tous les fichiers du répertoire cache datant de plus de xx minutes/heures etc... Ceci peut potentiellement avoir lieu par crontab, ou par l'activité sur le site, cf http://faqfclphp.free.fr/ chapitre crontab.
- prendre le md5 (ou toute autre signature simple) de la query string (i.e. tous les arguments reçus), vérifier si un fichier HTML de ce nom existe dans le répertoire cache (ne pas oublier l'appel à clearstatcache()...). Si oui, le renvoyer. Si non, générer le html correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Ceci est une approche bourrin qui ne marchera pas sur des morceaux, i.e. on cache toute la page, pas des bouts. Certains systèmes de templates gèrent des caches HTML partiels.
Il y a probablement moyen de faire beaucoup plus fin/intelligent/etc... mais cette première approche donnera un compromis correct simplicité de développement / résultat.
HTH, JG -- Les autres, c'est l'enfer.
John GALLET
En complément :
- prendre le md5 (ou toute autre signature simple) de la query string (i.e. tous les arguments reçus),
Plus précisement, on pourra différencier les arguments qui influent sur le contenu de la page de ceux qui ne gèrent, par exemple, que des droits d'accès mais n'influant pas sur le contenu. Gaffe aux données restées côté serveur ($_SESSION ou tout mécanisme similaire).
clearstatcache()...). Si oui, le renvoyer. Si non, générer le html correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Pour cette partie : http://fr2.php.net/manual/en/ref.outcontrol.php
Pour des caches locaux (exemple : un bout de drop down dont les options sont en SGBD pour simplifier leur modification par l'admin) on peut aussi carrément générer un vrai fichier html commun à tout le monde à chaque modification de la table (et un par jour pour faire bonne mesure).
Enfin, quelque part, c'est aussi le boulot d'un proxy. Jeter un oeil de ce côté là éventuellement, sur les techniques utilisées en tous cas.
a++; JG -- Les autres, c'est l'enfer.
En complément :
- prendre le md5 (ou toute autre signature simple) de la query string
(i.e. tous les arguments reçus),
Plus précisement, on pourra différencier les arguments qui influent sur
le contenu de la page de ceux qui ne gèrent, par exemple, que des droits
d'accès mais n'influant pas sur le contenu. Gaffe aux données restées
côté serveur ($_SESSION ou tout mécanisme similaire).
clearstatcache()...). Si oui, le renvoyer. Si non, générer le html
correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Pour cette partie : http://fr2.php.net/manual/en/ref.outcontrol.php
Pour des caches locaux (exemple : un bout de drop down dont les options
sont en SGBD pour simplifier leur modification par l'admin) on peut
aussi carrément générer un vrai fichier html commun à tout le monde à
chaque modification de la table (et un par jour pour faire bonne mesure).
Enfin, quelque part, c'est aussi le boulot d'un proxy. Jeter un oeil de
ce côté là éventuellement, sur les techniques utilisées en tous cas.
- prendre le md5 (ou toute autre signature simple) de la query string (i.e. tous les arguments reçus),
Plus précisement, on pourra différencier les arguments qui influent sur le contenu de la page de ceux qui ne gèrent, par exemple, que des droits d'accès mais n'influant pas sur le contenu. Gaffe aux données restées côté serveur ($_SESSION ou tout mécanisme similaire).
clearstatcache()...). Si oui, le renvoyer. Si non, générer le html correspondant en le bufferisant, l'écrire sur disque, et le renvoyer.
Pour cette partie : http://fr2.php.net/manual/en/ref.outcontrol.php
Pour des caches locaux (exemple : un bout de drop down dont les options sont en SGBD pour simplifier leur modification par l'admin) on peut aussi carrément générer un vrai fichier html commun à tout le monde à chaque modification de la table (et un par jour pour faire bonne mesure).
Enfin, quelque part, c'est aussi le boulot d'un proxy. Jeter un oeil de ce côté là éventuellement, sur les techniques utilisées en tous cas.
