Mise en cache et appels bdd

zamour · 26-01-2009 10:17:30

Bonjour

Tout d'abord bonjour à tous.

J'ai cherché sur le forum si le sujet avait déjà été creusé, mais je n'ai pas trouvé. Si j'ai mal cherché, excusez moi d'avance pour le doublon.

Voilà, pour pallier au problème de max_user_connections qui devient très frequent le soir sur mon forum, j'ai essayé de mettre en cache les pages index.php et viewforum.php en un premier temps. Je passe par jpcache parce qu'il fait une compression du fichier stoqué, ce qui est bien pratique.

J'ai modifié les fichiers post, edit et delete pour que le cache soir regénéré, uniquement pour la partie concernée, à chaque fois qu'une modification est effectuée au niveau de la bdd. La version cache n'est affichée que pour les utilisateurs non connectée, qui représentent l'essentiels du trafic.

Mon problème, c'est que le fichier cache est généré et mis à jour, qu'il est appelé et affiché (j'ai rajouté un echo time() et à ce niveu c'est correct), mais que néanmoins, des appels à la bdd sont effectuée, et que quand la limite est atteinte, j'ai quand même l'erreur max_user_connections. J'ai custumisé le message d'erreur, avec un redirect de 15 sec via javascript, et ça à aidé, mais le but est vraiment que les pages soient mise en cache "à 100%" et de ne faire aucun appel à la bdd.

J'ai retourné le code dans tous les sens, en commentent toute sorte de ligne ou d'appel à des fonctions), mais je n'arrive vraiment pas à identifier quelle ou quelles query sont quand même effectuées. L'appel au fonction de mise en cache se fait par include en tout début de script, juste après l'appel à common.php

Est-ce que quelqu'un à une piste pour moi? Si j'arrive à faire cela, je pourrais ensuite envisager la mise en cache de viewtopic aussi, si pas pour la totalité, au moins pour une partie des posts.

fanf73 · 26-01-2009 10:26:39

Je pense que tu le sais mais je le dis quand même : quoique tu mettes en cache, tu auras toujours au minimum un appel à la base de données dans le fichier common.php je crois, qui récupère les informations sur la personne qui visite ton forum (création de la variable $pun_user) même en temps qu'invité.

Je ne sais pas si te les as mis en cache également, mais la récupération des informations en pied de page (total message, de membres et de topic) demandent également un appel à la bdd.

En tout cas chapeau pour le travail que tu as effectué smile

zamour · 26-01-2009 10:50:51

Bonjour

Et merci de ta réponse.

J'ai vu cet appel, mais je pense que ce n'est pas le seul. Si mes souvenirs sont bons (j'ai fait tellement de tests que je me souviens plus exactement de ce que j'ai fait et ce qu'il me reste à faire sad ), même en modifiant (j'ai mis en dur le tableau avec les données du guest) ou en commentant les lignes en question, il en reste.

Mais il faudrait peut-être que je creuse du côté de pun_online un peu plus. J'ai désactivé dans les options du forum, et j'ai fait des tests en commentant le code, mais j'ai peut-être oublié quelque chose.

Une idée, comme ça, que j'avais, c'est peut-être que l'appel soit au niveau de la configuration, qui se ferait via requete à la bdd plutôt qu'au fichier de cache de celle-ci. Je dis cela car il me semble que l dernière fois que j'ai mis-à-jour le script, le n° de la version dans la bdd ne corresponait pas à celui du fichier cache. Probablement parceque je ne re-execute pas le fichier install.php quand je maj( je sais pas trop ce qui est refait ou pas, donc je m'abstient de toucher à un système qui tourne ;-).

Les reste dont tu parles, normalment ça doit être déjà dans le cache, je vais de <html> à </html> si je n'ai pas fait d'erreurs.

Pour le travail fait, j'ai pensé à le partager, mais il faut avant que j'aille un peu plus loin, avec un code plus propre notamment. Et il faut aussi que je le remette en place sur une version d'origine du script, histoire que les gens s'y retrouvent un peu smile L'ideal serait de passer par quelque chose qui ne demande pas de modifier le code source d'origine, mais là, c'est au delà des mes capacités limitées.

fanf73 · 26-01-2009 11:14:13

Tu peux essayer de te mettre en mod Debug, ça t'indiquera le nombre de requête exécutée : http://www.punbb.fr/aide/doku.php/faq?# … _l_activer

La configuration passe exclusivement par les fichiers cache, c'est d'ailleurs pour cela que le numéro de version n'est pas toujours à jour même après modifié le-dit numéro dans la base de données : c'est toujours l'ancien qui se trouve dans le fichier cache.

zamour · 26-01-2009 11:19:58

Milles merci à toi fanf73

Je vais tester ça dès ce soir j'espère, et vous tiens au courant. Je pense que la mise en cache, ne fusse que partielle, est une fonction importante qui manque pour l'instant au forum. Ca pourrait servir à plus d'un.

fanf73 · 26-01-2009 11:34:19

Je ne suis pas sûr du résultat que tu obtiendras en activant le mod debug avec les modifications que tu as apportées, mais j'espère qu'il te donnera un résultat smile .

zamour · 26-01-2009 12:12:15

Bon ben... comment idre... je suis pas dans la merde yikes )

Alors... pour un user connecté, il y a, pour la page d'index, 8 queries faites.
Pour un user non connecté, passant par le cache... 7 sad

La seule difference c'est qu'il n'y à pas de requété effectuée pour vérifier le nombre de messages privés.

En gros, mon cache, comme il est, il ne sert à rien.

mais bon, au moins là j'ai la liste des requesteseffectuées, je vais pouvoir aller voir requete par requete ce qui est fait.

:-(

Mpok · 28-01-2009 21:58:45

Euh... huh
La principale caractéristique de Fluxbb (ou Punbb) est justement d'être optimisé en termes de requêtes et/ou de légèreté.
Même si l'idée d'essayer d'améliorer encore plus le système est justifiée sur le fond, il semble un peu illusoire de s'attendre à des résultats probants : quand on est à 6 ou 7 requêtes par page, on a déjà atteint les limites de ce qu'il est possible de faire.

Ensuite, il y a les mods : elles sont généralement de qualité bien inférieure au code principal, et peuvent certainement être améliorées.

zamour · 29-01-2009 15:54:47

Bonjour Mpok

Je pense que je n'ai pas du être clair au niveau de ce que je souhaite obtenir.

Il ne s'agit pas de penser amèliorer les requestes du code. Encore que, si il y a des fonctions, telles que pun_online, que l'on ne souhaite pas implèmenter, optimisées ou pas, ce sont dans ce cas de figure des requètes inutiles.

Mon but, n'est pas de faire de meilleures requetes, mais de faire 0 requetes en passant par un système de mise en cache. Pourquoi aller repiocher dans la bdd des données statiques? Ce n'a pas de sens. Quand une modif est faite, on crée la page statique, quand elle subit une modification, on la met à jour.

Si on prend par exemple les anciennes discussions, il y en a qui ne changeront plus jamais. Pourquoi les garder en "live" tout le temps? Tu fais du statique, et tu mets à jour sur demande au moment voulu. Certaines données mineures comme le nombre de message par user peuvent changer? Ok, alors soit on met en place un cache sur certaines parties seulement de la pge, soit on peut regénérer le cache automatiquement une fois tous les x temps par un chron aux heures de faible affluence sans que ça ne gène personne.

Les possibilités sont nombreuses. Et du HTML simple sera toujours plus rapide que ma plus optimisée des requètes MySQL.

Par contre, j'arrive toujours pas à mettre en cache le tout sur punbb. La création de cache est parfaite, tout y est, mais les requètes sont quand même effectuès même si c'est le cache qui est affiché au final. Allez comprendre. Ca doit surement être un truc tout bête en plus...

Mpok · 29-01-2009 22:04:07

Si, si.. j'ai bien compris (au moins en gros) ce que tu voulais faire..
Mais je persiste à croire que cela ne servira pas à grand chose au final.
(ceci dit, je peux me tromper.. wink )

Plus tu vas mettre d'infos en cache, et plus le processus de 'parsing' de ce cache sera long et compliqué. Du coup, le gain par rapport à une requête mysql sera réduit.
D'autre part, l'avantage de piocher dans une base de données est de permettre certaines opérations "groupées" (par les JOIN). Ceci n'est pas possible avec des fichiers texte (le cache).

Donc la mise en cache n'est intéressante QUE pour :
- des données qui ne sont pas modifiées (ou peu).
- des données unitaires, qui ne sont pas liées à d'autres.
Et c'est précisemment ce que fait DEJA Fluxbb (avec par exemple la mise en cache de la table 'config').

Otomatic · 30-01-2009 10:35:14

Bonjour,

À moins d'être son propre hébergeur, on ne peut pas « jouer » avec le cache des requêtes MySQL.

Les paramètres sont gérés par le fichier de configuration de MySQL, entre autres :
query_cache_size=
table_cache=
tmp_table_size=
thread_cache_size=

Mais, de toutes manières, les requêtes MySQL seront toujours exécutées, que ce soit en direct ou depuis le cache ; bien sûr, depuis le cache, elles seront plus rapides.

fanf73 · 30-01-2009 11:36:35

J'ai du mal à comprendre ce qui nous empêche de générer (par exemple) un fichier index.html à chaque nouveau message, fichier qui sera appelé chaque fois qu'un invité demandera l'index du forum huh

Après ce n'est peut-être pas tout à fait ce que demande / à fait zamour.

Otomatic · 30-01-2009 12:12:37

fanf73 a écrit :

J'ai du mal à comprendre ce qui nous empêche de générer (par exemple) un fichier index.html à chaque nouveau message, fichier qui sera appelé chaque fois qu'un invité demandera l'index du forum

Et... comment feras-tu pour savoir que c'est un invité ?

fanf73 · 30-01-2009 12:19:41

Quand on appelle le fichier index.php, on teste après l'inclusion du fichier common.php pour voir si le visiteur est un invité ou pas. Ça ne ramène pas le nombre de requêtes à 0 mais ça enlève toutes celles pour l'affichage des informations sur l'index.

Mais je vois où vous voulez en venir : qu'il y ai 2 ou 8 requêtes, ça fait toujours 1 connexion à la base de données donc la limitation du nombre de connexions simultanées est toujours atteinte.

@oldie-2 : le passage par le cache n'est là que pour les invités, donc pas de soucis de droits particuliers / messages lus ou pas.

Dernière modification par fanf73 (30-01-2009 12:21:11)

zamour · 31-01-2009 16:18:40

Bonjour à tous

Désolé si je n'ai pas répondu plus vite, mais j'étais vraiment débordé.

Alors...
Comme le dit fanf73, le cache ne serait là que pour les guests, ce qui résout tout une série de problèmes pour les droits.

Dans le cas particulier de mon forum, tout le monde peut tout voir, la seule différence c'est qu'il faut être loggués pour poster. Pas de forums à accès restreint ou autres donc, en principe, il suffit de vérifier si c'est is_guest et c'est bon.

De ce que j'ai compris (mais je peux me tromper), cette vérification est faite sur base d'absence/présence d'un cookie qui contient l'identifiant/id du visiteur.
Sans compliquer la chose, il suffirait de voir si c'est un id guest, et dans ce cas afficher le cache, pour tous les uatres cas, version dynamique. Et jusque là, en principe, pas de connections à la bdd d'office.

Après, si c'est un guest, il y a une connection bdd pour récupérer les infos du guest. Mais pourquoi ne pas passer par un fichier cache_guest comme on le fait pour le cache de la config? A mon avis ça doit être jouable sans trop de difficultés.

Après, on peut affiner la chose. Par exemple on peut laisser la query pour l'update de num_views d'un topic tourner en background, si la bdd est dispo elle le fait, si non le contenu s'affiche quand même et le cache est maj à la prochaine ecriture. Même si pendant une heure ou deux ne num_views est pas à jour, perso, ça ne me pose pas de problèmes particuliers, je préfère ça à avoir un site down toutes les 5 minutes, parce qu'un bot est en train de crawler à mort le forum (et je me vois mal dire à googlebot "dégage coco").

Idem pour les membres en ligne. Je peux m'en passer.

Ok, je vais perdre certaines fonctionnalités. Mais si je ne les utilise pas, pourquoi les faire tourner de toute façon?

Et sur la page d'index, est-ce qu'il y a vraiment besoin d'avoir des requêtes en bas de page ou à chaque affichage on contrôle le nombre de membres, de posts et de topics? pourquoi ne pas mettre ça dans un fichier cache mis à jour à chaque modification de ces infos?

Et de toute façon, chaque requête non effectue, représente un gain non négligeable dans certains cas. Moi par exemple, après avoir passé deux jours à regarder mes queries en live, je me suis rendu compte que celle qui me plombe le site c'est celle de rss.php. Pourquoi tout d'un coup, j'en sais rien, mais c'est de la que vienne mes problèmes. J'ai essayé de mettre tout en nofollow, ça n'a rien changé. J'ai essayé de carrément enlever les liens vers les rss des topics, ça n'a pas donné de gros changements. Le problème vient de bots, parce que j'ai le problème même a 4h du mat sans aucun visiteur on ligne. Mais si mes rss étaient en cache, mon problème serait résolu. Et le cache est généré, je vois mes fichiers, ils sont complets.

Pour la mise en cache de viewtopic, ça serait aussi le même principe. Il faudrait juste affiner le système pour que les fichiers ne se retrouvent pas par milliers dans le même dossier, mais on pourrait imaginer une arborescence de ce genre

Index > forum > n topic > post
2n topic > post

Et si pour le viewforum on voulait optimiser le tout, il faudrait faire une pagination inversée, avec sur la page 1 les topic les plus anciens, et sur la page n les plus récents. Comme ça on n'efface que les pages en cache concernées, et pas toutes les n pages pou faire glisser d'un ligne un topic. Exactement ce qui se passe pour viewtopic

@fanf73 > je t'oublie pas. Dès que j'ai 5 minutes pour trier mon répertoire, je t'envoie les modifs faites. Il y en a pas des masses, à la limite le plus simple c'est que je les sortes elles et te les envoie.

Mpok · 31-01-2009 17:38:03

Quelques avis :

- ok pour le "cache_guest", ça devrait effectivement être jouable.
- cependant, ça ne suffit pas pour ne pas avoir de connexion à la bdd : il faut également supprimer la vérification des IP bannies, et supprimer l'enregistrement des invités dans la table online (et sur ce dernier point, je ne suis pas sûr des conséquences..).
- "si la bdd est dispo elle le fait" : et comment tu détermines si elle est "dispo" ???
- googlebot ne "crawl pas à mort" (c'est même le contraire, on aimerait souvent qu'il crawl un peu plus.. mdr ). D'autres robots moins 'respectueux' le font peut-être (mais alors, il suffit de les bloquer dans le robots.txt).
- pour les rss, ça peut effectivement être intéressant de les mettre en cache, mais ça dépend un peu de l'activité du forum : tu vas être obligé de parser tes fichiers cache à chaque post (puisque tu ne peux pas faire une requête globale), donc tu risques de perdre en rapidité ce que tu vas gagner en connexions (mais bon, on va dire que c'est jouable si tu ne mets que les 10 dernières discussions).

Lyconide · 31-01-2009 19:06:03

- "si la bdd est dispo elle le fait" : et comment tu détermines si elle est "dispo" ???

L'accès a la bdd renvoie une erreur : "trop de connexion", donc plutôt que d'afficher l'erreur, il appel le cache happy

zamour · 02-02-2009 11:52:41

Tout à fait, c'est d'ailleurs en partie ce que je fais déjà avec un message d'erreur personnalisé pour les erreurs mysql avec un redirect après 15 secondes par javascript.

@Mpok : la liste des adresses bannies devrait se trouver dans un fichier cache déjà maintenant si je ne me trompe pas.
Le pun_online, à vérifier, mais je pense que ce n'est que pour les stats des membres connectés à l'instant t.

Googlebot crawle "beaucoup" (enfin, tout est relatif) certains sites yikes ) C'est pas pour rien si dans les webmasters tools tu peux ralentir le crawl. Dans mes stats, c'est le plus gros consommateur de bande passante par exemple, et de loin. 1.4 gb sur les 26gb au total, 3 fois plus que Yahoo.

Après, loin de moi l'idée de critiquer punbb. Si je n'étais pas convincu que c'est ce qu'il se fait de mieux pour mes besoins, je ne l'utiliserais pas. Mais comme tout script, il répond aux besoins de la masse, et chaqu'un de nous peut avoir des besoins particuliers qui ne sont pas pris en compte. D'ailleurs, l'affichage du forums sans connection à la bdd quand on a déjà suffisament d'infos, est un ticket déjà crée par les développeurs, même si il n'est pas dans leurs priorités.

Archives FluxBB.fr

#1 26-01-2009 10:17:30

Mise en cache et appels bdd

#2 26-01-2009 10:26:39

Re : Mise en cache et appels bdd

#3 26-01-2009 10:50:51

Re : Mise en cache et appels bdd

#4 26-01-2009 11:14:13

Re : Mise en cache et appels bdd

#5 26-01-2009 11:19:58

Re : Mise en cache et appels bdd

#6 26-01-2009 11:34:19

Re : Mise en cache et appels bdd

#7 26-01-2009 12:12:15

Re : Mise en cache et appels bdd

#8 28-01-2009 21:58:45

Re : Mise en cache et appels bdd

#9 29-01-2009 15:54:47

Re : Mise en cache et appels bdd

#10 29-01-2009 22:04:07

Re : Mise en cache et appels bdd

#11 30-01-2009 10:35:14

Re : Mise en cache et appels bdd

#12 30-01-2009 11:36:35

Re : Mise en cache et appels bdd

#13 30-01-2009 12:12:37

Re : Mise en cache et appels bdd

#14 30-01-2009 12:19:41

Re : Mise en cache et appels bdd

#15 31-01-2009 16:18:40

Re : Mise en cache et appels bdd

#16 31-01-2009 17:38:03

Re : Mise en cache et appels bdd

#17 31-01-2009 19:06:03

Re : Mise en cache et appels bdd

#18 02-02-2009 11:52:41

Re : Mise en cache et appels bdd

Pied de page des forums