Système de cache directement dans la base de données Mysql

[finstreet]

Bonjour

Dans l'optique de poursuivre l'allègement de ma charge serveur -j'y arrive d'ailleurs plutôt bien en ce moment-, j'envisage la possibilité de créer des pages en cache. Mais ces pages ne seraient pas générées et laissées sur le serveur mais enregistrées dans la base de données, dans une table. A chaque page est associée une url, et à chaque url un contenu.

Au premier chargement d'une url dans la journée, le code est généré et intégré dans une table. Comme ca, le prochain chargement ne nécessitera qu'une seule requête affichant la totalité de la page. La table sera vidée tous les soirées (ouais j'ai envie lol) et ne devrait pas dépasser les 100.000 lignes à la fin de la journée.

Ma question qui en est une, sans en être une : est ce que ça peut avoir un quelconque intérêt ? Enfin le truc plutôt : quels sont les limites d'un tel système ? Je cherche plutôt à me dire que l'idée est mauvaise, car ça va me prendre pas mal de temps à développer lol

Marchi

[forty]

un cache fichier a l'avantage de pouvoir marcher même si la base ne marche pas.

[blman]

ouep, tu te ferais moins chier à générer un fichier et à le regénérer si ça date d'expiration de cache est dépassée...

[Julia41]

Ca peut être pas mal si tes pages sont longues à être compilés, vont chercher du contenu ailleurs (parseur RSS par exemple).

Sinon, je ne vois pas trop d'intêret.

En technique de cache pas mal, tu as memcache (je suis fan perso), tu peux stocker tout ce que tu veux dedans et vu que c'est directement sur la RAM, tu n'as pas d'accès disque pour cette partie (très rapide donc).

Sinon, regarde aussi pour ton moteur de cache SQL, le mode MEMORY est pas mal mais lock comme du MyISAM.

[biddybulle]

J'ai du mal également à voir l'interêt, un accès http à une page/fichier .html (Pas d'accès BDD, pas de php ou autre) est plus rapide.

[fandecine]

Une petite recette très efficace pour faire un cache de données

Tu crées une classe structurée de la sorte :

Code: Tout sélectionner

1 - Vérification de l'existence  du fichier de données
2 - si il existe pas, tu fais tes requêtes à la BDD
   A - tu stockes les données dont tu as besoin pour générer ta page dans un tableau qui sera accéssible grâce aux fonctions de ta classe
   B - tu sérialise le tableau et tu stocke le résultat dans un fichier
3 - si le ficheir existe
   A - tu le lis pour récuperer son contenu
   B - tu desérialise les données dans un tableau accessible grâce aux fonctions de ta classe


Cette méthode présente l'avantage de ne garder en cache que ce qui est nécessaire (les données et non le HTML) donc un gain de place et puis cela permet de conserver l'indépendance entre le contenu et la présentation du contenu. Il est également possible de fractionner le cache, par exemple sur une page ou tu présente une fiche produit et la liste des derniers produits ajoutés tu stocke les deux dans des fichiers différents pour que la mise à jour de l'un ne nécessité pas de régénérer l'autre.

[jcaron]

+1 pour memcached.

Jacques.

[spout]

Il y a APC aussi http://php.net/manual/fr/book.apc.php
(J'ai choisi celui là car il sera intégré par défaut à PHP6)

[Leonick]

Ca a l'air pas mal, mais ça ne peut s'installer que sur un dédié ?

[raljx]

en effet comme le dit bidibulle l'acces a une page html est naturellement rapide.

j'opterai donc :
------------------
soit pour une mise en cache classique des pages,
soit par l'execution d'un cron qui te genererai toutes tes pages html d'un coup (style lancé le matin à 5h00) et effacer le cache la nuit ...

niveau dev 1/2 journée devrait suffire pour des performances plus que correctes ...

[spout]

Je vois plutôt du cache de l'output HTML avec PEAR::Cache_Lite sur disque plutôt qu'en BDD.

Dans le "controller":
Si pas de données $_POST et si membre pas loggué
=> Activer cache
Sinon
=> Désactiver cache

Ce n'est pas dur à mettre en place:
http://pear.php.net/manual/en/package.caching.cache-lite.intro.php

[finstreet]

Ah ben c'est pointu Bon vais creuser un peu tout ca Pas mal de notions à assimiler encore... mais cool j'ai plein de raisons de ne pas choisir cette solution

Marchi pour tout

[Julia41]

Il y a pas mal d'intérêt à utiliser du cache dans une base de données plutôt que sur le disque.
Si tu utilises plusieurs dédiés et une base MySQL, plutôt que de dispatcher tes fichiers de cache ou de les générer sur chaque serveur, tu les balances partout (mais bon, dans ce cas memcache est plus rentable).

Tout plein de solution s'offre à toi en tout cas mais le cache SQL est une bonne solution aussi (les accès DD ne sont pas toujours plus rapide que mysql avec du query cache suffisament performant surtout sur des serveurs de type "DD mutualisé" à la cloud/RPS).

[raljx]

maaa finstreet il dit pas s'il a plusieurs serveurs (mysql, front, mail) ...
si tu pars dans l'optique d'un seul serveur pour tout un systeme de cache classique fonctionne tres bien...
y fait combien de VU le mosieur ?

[finstreet]

y'a déjà un QUERY Cache en fait. Ca permet de bien réduire le temps mais je n'ai jamais su quand le cache se vidait. Je pense m'orienter vers une solution intermédiaire, à savoir sélectionner des pages qui n'évolueront plus ou pas avec le temps (sauf action de ma part) et créer à la volée des pages html. Car y'a des pages qui évoluent 30 fois par jour, et là ca ne sert à rien de mettre en cache.

En tout cas, suis passé avec pas mal de boulot à une charge serveur constante aux alentours des 50-60% contre des minimums à 200% avant