3 - Le site : philosophie, organisation, problèmes...

Ce n'est pas une bonne idée car tu sollicite ta base de données plus que nécessaire pour rien en donnant de accès à des fonctionnalités qui de toute façon ne servent qu'à celui qui a besoin de revenir sur une version antérieure de la page.

Attend de régler avant ton problème de crash réguliers avec le forum. C'est moi même qui avait opté pour cette configuration et c'est pour ces points que l'avait faite.

Après bien entendu tu es libre de ne pas en tenir compte et de faire à ton idée.

Merci pour ton commentaire.

Ceci dit, il y a quelque chose qui sonne faux dans cette réflexion que tu proposes ici : "tu sollicite ta base de données plus que nécessaire".

En quoi activer cette fonction (ou une autre d'ailleurs) "solliciterait" d'avantage la BDD ? La BDD n'est sollicitée qu'au moment où l'on demande à une page de s'afficher (et encore, il y a un système de cache qui fait qu'une page affichée est rechargée directement sans passer par la BDD si je me souviens bien). Du coup, je pense que tu fais fausse route sur la base réflexive.




C'est une mauvaise analyse, elles (les pages "historiques") servent surtout à montrer "qui a écrit quoi". Le BY de la licence CC-BY-SA du contenu du site (sauf exception).




Je ne pense pas que l'affichage de l'historique et les crashs du forum soit liés. De toute façon, on verra bien ces jours-ci.




OK.


Olivier

Que je sache jusqu'à preuve du contraire le contenu est bien dans la base de données. Et je n'ai pas dit ni même écri que les crash et l'historique soient lié je dit juste que si t’élimine les problème et autres sources de plantage t'aura plus facile à détecter là ou ça foire.

Donc ça c'est mon "analyse qui sonne faux" mais pas plus que ... enfin bref ...

Tout le contenu du site y est oui. Ce qui me pose cette question : pourquoi y aurait-il une différence entre demander du contenu sur une page "normale" (type wiki, forum, article ou autre) et une page concernant l'historique ? Ou, en utilisant tes mots, "en quoi ceci solliciterait-il la base de données plus que nécessaire" ?

Ce n'est qu'un lien qui est soit affiché, soit caché, donc pour un visiteur humain (qui n'ira pas forcément cliquer sur ce lien) ça ne chargera pas plus la base de données.

Par contre je pense que la sollicitation peut venir des moteurs de recherche qui vont systématiquement visiter et revisiter l'historique. Dans ce cas il pourrait être pertinent de bloquer la page tiki-pagehistory.php pour les robots (je vois d'ailleurs que c'est déjà fait : http://www.linuxmao.org/robots.txt)

Ça marchera pour les robots qui sont respectueux des règles du robots.txt mais les autres au contraire vont s'y engouffrer.

Et ce n'est pas juste un lien il y a une action pour aller chercher l'archive de la page en question et en ce sens vu le nombre de pages plus le nombre de version pour chaque page bin ça fait un paquet de page tout ça. C'est quoi 1500~1800 pages avec un historique de 20~30 version au bas mot par page, fait le compte et encore je ne parle pas des pages qui sont à plus de 200 versions ...

Exact favardin.

@utilisateur_anonyme, je viens de vérifier dans les logs du site et en dehors des demandes concernant :

• l'historique de la page sunvox (celle qui est mentionné sur linuxfr et qui attire donc des clics d'humains curieux),
• l'historique de la page zynaddsubfx_moteurs (la page la plus active ces jours-ci),

il y a 9 "hints" sur des pages d'historiques depuis que j'ai réanimé cette fonction il y a 2 jours.

Dans ces 9 demandes, il y en a :

• 4 différentes qui ont mon adresse IPs
• 3 sur la page bristol qui viennent de la même adresse IP (certainement un utilisateur qui s'intéressait à cette page)

Il en reste donc 2 qui elles, viennent bien de robots (indiqué dans leur user agent) qui ne semblent pas respecter le robot.txt du coup.

XX.XXX.XXX.XXX - - [11/Feb/2016:16:01:33 +0100] "GET /tikiwiki/tiki-pagehistory.php%3Fpage=configurations%2520mat%25C3%25A9rielles%26diff2=89%26diff_style=unidiff HTTP/1.0" 301 605 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.5; http://www.majestic12.co.uk/bot.php?+)"

XX.XXX.XX.X - - [12/Feb/2016:05:14:02 +0100] "GET /tikiwiki/tiki-pagehistory.php%3Fpage%3Dconfigurations%2520mat%25C3%25A9rielles%26diff2%3D89%26diff_style%3Dunidiff HTTP/1.1" 301 586 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)"


Bref, pour l'instant, nous sommes à 1 hint par jour. Sachant que pour le mois de Janvier, linuxmao était à plus de 2.200.000 hits sur le mois, je ne pense donc pas que ce soit ça qui fasse tomber le site en surchargant la BDD.


Olivier

@favardin, puisque tu t'y connais un peu en robots.txt, ce que je note dans ces 2 hints de robots, c'est qu'ils cherchent tout deux une adresse commençant par "/tikiwiki/" et se référant à la page "configuration matérielles". Ces 2 indices me mettent la puce à l'oreille : ils cherchent une vieille page (qui n'est plus trop maintenue de nos jours, et qui est même dépréciée) mais qui a eu son heure de gloire "il fut un temps" (dédicace à "Lucky Number Slevin"). Ce qui expliquer que, du coup, les hints demandés aient le "/tikiwiki/" dans l'adresse car ça date de l'époque où la redirection n'était pas effective. Du coup, j'ai l'impression qu'un hint sur "/tikiwiki/tiki-pagehistory.php..." n'est pas protégé par le fichier robots.txt. Me trompé-je ? (J'espère que c'est clair, mais ça ne l'est peut être pas car j'ai mal au crâne aujourd'hui et mon cerveau est un peu brouillon. S'il y a besoin de clarification, demande moi )

Il peut y avoir une problématique avec le htacess qui lui reconverti les anciennes urls du type 3w.lmao/tikiwiki/accueil vers 3w.lmao/accueil
Du coup /tikiwiki/tiki-pagehistory.php pourrait redevenir valide. (en fonction des pages si elle existent encoure ou non)
Mais à partir de là faut demander à des gens qu connaissent bien les règles du htaccess pour contrer les accès indésirables.

Ce n'est pas deux jour que tu peux voir le résultat effectif d'une telle action c'est comme pour les résultats de recherches via google il a fallu patenter pour avoir du concret.

• 12 février : 2 occurrences
• 11 février : 5 occurrences
• 10 février : 2 occurrences
• 9 février : 2 occurrences
• 8 février : 2 occurrences
• 7 février : 3 occurrences
• 6 février : 1 occurrence
• 5 février : rien
• 4 février : 1 occurrence
• 3 février : 2 occurrences
• 2 février : (rien)
• 1 février : (rien)

• 20 février : 5 occurrences
• 19 février : 13 occurrences
• 18 février : 3 occurrences
• 17 février : 0 occurrence
• 16 février : 6 occurrences
• 15 février : 4 occurrences
• 14 février : 7 occurrences
• 13 février : 12 occurrences

• 29 février : 14 occurences
• 28 février : 24 occurences
• 27 février : 8 occurences
• 26 février : 17 occurences
• 25 février : 5 occurences
• 24 février : 9 occurences
• 23 février : 69 occurences
• 22 février : 15 occurrences
• 21 février : 8 occurrences

Bon, pour moi, c'est bon ici. Je mets un [FAIT] dans le titre du fil, et je repasserai d'ici un mois pour vérifier les logs apache et voir si ça n'a pas trop augmenté. Je ferais ça pendant quelques mois puis fermerai définitivement ce fil s'il n'y a pas de problème en vue.

À peine 10 occurrences aujourd'hui. Je fermerai ce fil lors de ma prochaine maintenance.