J'avais lu dans la doc de Spip que l'un des intérêts du système de cache de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir aller chercher la version "cachée" d'une page en cas d'indisponibilité du serveur MySQL.
Extrait de la doc :
"les fichiers cachés sont exploités même si la base de données est « tombée », ce qui garantit le site contre des pannes transitoires du serveur mySQL."
Je viens donc de faire un test en local, avec le squelette par défaut de Spip. J'ai désactivé le moteur de recherche et les statistiques.
J'affiche ma page à plusieurs reprise, puis je coupe MySQL. Et bien Spip ne vas pas chercher une version de ma page en cache, mais m'affiche le magnifique message suivant :
"Site en travaux
Attention : un problème technique (serveur MySQL) empêche l'accès à cette partie du site. Merci de votre compréhension."
Ca c'est pénible, parce que chez les hébergeurs mutualisés, c'est pas rare que le serveur MySQL ne répondent plus temporairement. Sur les sites que je développe moi-même, ma gestion de cache gère les pannes MySQL.
Faut-il que j'en conclu que Spip ne le permet pas, contrairement à ce qui est écrit dans la doc ? Je précise bien évidemment que mes caches ont une durée de 24h, et mon soucis ne vient donc pas d'un cache qui arriverait à sa fin.
J'avais lu dans la doc de Spip que l'un des intérêts du système de cache
de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir
aller chercher la version "cachée" d'une page en cas d'indisponibilité
du serveur MySQL.
Extrait de la doc :
"les fichiers cachés sont exploités même si la base de données est
« tombée », ce qui garantit le site contre des pannes transitoires du
serveur mySQL."
Bonjour
A une époque, lorsque j'avais des sites chez free.fr, j'avais
observé une accélérations brutale de la vitesse du site... parce que
la BD MySQL ne répondait plus et que Spip n'utilisait que le cache.
Donc, ça marchait bien à une époque. il n'y a pas de raisons que ça
ne fonctionne plus...
Je viens de refaire le test, et je confirme bien que si MySQL "tombe", mes pages génèrent le message d'erreur indiqué.
"Site en travaux - Attention : un problème technique (serveur MySQL) empêche l'accès à cette partie du site. Merci de votre compréhension."
Ma version de Spip ? La 1.9.2c
Il s'agit d'une installation toute neuve (pas une mise à jour).
D'autres personnes peuvent-elles faire un test en local ? C'est assez vite fait : pour ceux qui ont Wamp ou EasyPHP, en un clic de souris, on coupe MySQL et le relancer est aussi simple.
Merci par avance !
Grégoire a écrit :
YMDK a écrit :
Bonjour,
J'avais lu dans la doc de Spip que l'un des intérêts du système de cache de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir aller chercher la version "cachée" d'une page en cas d'indisponibilité du serveur MySQL.
Extrait de la doc :
"les fichiers cachés sont exploités même si la base de données est « tombée », ce qui garantit le site contre des pannes transitoires du serveur mySQL."
Bonjour
A une époque, lorsque j'avais des sites chez free.fr, j'avais
observé une accélérations brutale de la vitesse du site... parce que
la BD MySQL ne répondait plus et que Spip n'utilisait que le cache.
Donc, ça marchait bien à une époque. il n'y a pas de raisons que ça
ne fonctionne plus...
Je viens de refaire le test, et je confirme bien que si MySQL "tombe", mes pages génèrent le message d'erreur indiqué.
"Site en travaux - Attention : un problème technique (serveur MySQL) empêche l'accès à cette partie du site. Merci de votre compréhension."
Ma version de Spip ? La 1.9.2c
Il s'agit d'une installation toute neuve (pas une mise à jour).
pour que le cache fonctionne, il faut qu'il y ait des pages en cache, c'est à dire un spip qui a tourné suffisament longtemps pour que toutes les pages aient été générées et mise en cache ( pas de cache nul!!)
D'autres personnes peuvent-elles faire un test en local ? C'est assez vite fait : pour ceux qui ont Wamp ou EasyPHP, en un clic de souris, on coupe MySQL et le relancer est aussi simple.
Merci par avance !
Grégoire a écrit :
YMDK a écrit :
Bonjour,
J'avais lu dans la doc de Spip que l'un des intérêts du système de cache de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir aller chercher la version "cachée" d'une page en cas d'indisponibilité du serveur MySQL.
Extrait de la doc :
"les fichiers cachés sont exploités même si la base de données est « tombée », ce qui garantit le site contre des pannes transitoires du serveur mySQL."
Bonjour
A une époque, lorsque j'avais des sites chez free.fr, j'avais
observé une accélérations brutale de la vitesse du site... parce que
la BD MySQL ne répondait plus et que Spip n'utilisait que le cache.
Donc, ça marchait bien à une époque. il n'y a pas de raisons que ça
ne fonctionne plus...
pour que le cache fonctionne, il faut qu'il y ait des pages en cache, c'est à dire un spip qui a tourné suffisament longtemps pour que toutes les pages aient été générées et mise en cache ( pas de cache nul!!)
Mon cache n'est bien évidemment pas nul. J'ai un article, j'affiche à tour de rôle l'article et la page d'accueil, l'article et la page d'accueil, ...
J'ai vérifié le dossier cache, il contient bien des fichiers.
Dans l'admin de Spip, si je clique sur "vider le cache", il m'indique que mon cache contient actuellement 112,6 Ko.
Je coupe alors MySQL, et j'obtiens le message d'erreur déjà indiqué dans mes précédents messages.
Evidemment, je n'ai pas la variable, dans l'URL, qui recalcule la page. J'ai même fait le test en supprimant tous mes coockies et historique, et sans me connecter à l'admin de Spip.
Je pense que le mieux serait que d'autres personnes fassent le test.
J'affiche ma page à plusieurs reprise, puis je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache, mais m'affiche le
magnifique message suivant :
"Site en travaux
Attention : un problème technique (serveur MySQL) empêche l'accès à
cette partie du site. Merci de votre compréhension."
J'affiche ma page à plusieurs reprise, puis je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache, mais m'affiche le
magnifique message suivant :
"Site en travaux
Attention : un problème technique (serveur MySQL) empêche l'accès à
cette partie du site. Merci de votre compréhension."
J'ai fait le même constat ...
Bonjour Thierry,
Comment as-tu procédé pour ton test (local, distant) ?
Si local, Wamp, EasyPHP ?
Version de Spip ?
J'affiche ma page à plusieurs reprise, puis je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache, mais m'affiche le
magnifique message suivant :
"Site en travaux
Attention : un problème technique (serveur MySQL) empêche l'accès à
cette partie du site. Merci de votre compréhension."
J'ai fait le même constat ...
Bonjour Thierry,
Comment as-tu procédé pour ton test (local, distant) ?
Si local, Wamp, EasyPHP ?
Version de Spip ?
Merci à toi.
_______________________________________________
Pour info sur une 1.9.3 svn en local:
Si je coupe MySql [easyphp 1.8] et que je vide le cache du navigateur, j'obtiens une belle page blanche alors que j'ai bien un dossier cache bourré à craquer..
Avant d'ajouter des fonctionnalités, je pense que les prochaines versions de Spip devraient améliorer tout ceci, pour permettre une montée en charge moins problématique d'un site Spip.
Pour les pages en cache, quand on voit le paquet de requêtes lancées au serveur MySQL (même en désactivant les stats, je pense par exemple aux requêtes Meta), ça fait peur. L'idéal serait d'arriver à 0 requête lorsque la page est en cache (or stat, évidemment).
Vous pouvez faire un essai : pour les utilisateurs de Wamp (sais pas comment on fait pour EasyPHP), vous ajoutez cette ligne dans le fichier my.ini :
log=H:/Multimedia/logmysql.txt
ce qui est après le signe '=' correspond à l'emplacement d'un fichier texte de votre choix.
Le fichier contiendra toutes les requêtes effectuées par MySQL. Et quand on voit les requêtes générées par Spip...
quo-libris a écrit :
YMDK a écrit :
Olivier THIERRY a écrit :
Le 21/10/07, YMDK<ymdk@free.fr> a écrit :
Bonjour,
J'affiche ma page à plusieurs reprise, puis je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache, mais m'affiche le
magnifique message suivant :
"Site en travaux
Attention : un problème technique (serveur MySQL) empêche l'accès à
cette partie du site. Merci de votre compréhension."
J'ai fait le même constat ...
Bonjour Thierry,
Comment as-tu procédé pour ton test (local, distant) ?
Si local, Wamp, EasyPHP ?
Version de Spip ?
Merci à toi.
_______________________________________________
Pour info sur une 1.9.3 svn en local:
Si je coupe MySql [easyphp 1.8] et que je vide le cache du navigateur, j'obtiens une belle page blanche alors que j'ai bien un dossier cache bourré à craquer..
du calme les basses !
d'après fil sur la liste dev, le cache ne bénéficie pas aux admins.
pour tester, il ne faut pas être connecté admin.
peux tu essayer après t'être déconnecté ?
"YMDK" <ymdk@free.fr> a écrit
J'avais lu dans la doc de Spip que l'un des intérêts du système de cache
de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir
aller chercher la version "cachée" d'une page en cas d'indisponibilité
du serveur MySQL.
Je viens donc de faire un test ....je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache,
Fil a répondu sur la liste dev : il ne faut pas être connecté avec son
cookie d'admin mais aller sur le site en anonyme...
"YMDK" <ymdk@free.fr> a écrit
J'avais lu dans la doc de Spip que l'un des intérêts du système de cache
de Spip, c'était, outre d'accélérer l'affichage des pages, de pouvoir
aller chercher la version "cachée" d'une page en cas d'indisponibilité
du serveur MySQL.
Je viens donc de faire un test ....je coupe MySQL. Et bien Spip
ne vas pas chercher une version de ma page en cache,
Fil a répondu sur la liste dev : il ne faut pas être connecté avec son cookie d'admin mais aller sur le site en anonyme...
Je viens de tester et c'est exactement ça. Ça marche si on vient en anonyme et pas si on a un cookie admin. Je n'ai pas eu le temps dans la journée, ni de tester ni de repercuter.