Page auteur, récupération des posts partagés, lenteur systématique · Issue #295 · seenthis/seenthis_squelettes · GitHub

@b_b @arno @rastapopoulos @les_autres, j’ai besoin d’aide pour prendre des décisions SVP :-) Aide sur SPIP et le fonctionnement de son répertoire tmp, aide sur Sphinx et son déploiement désormais, etc. Ce n’est pas grand chose, je pourrais improviser, mais bon. Si je pouvais éviter de tâtonner :-)

Merci pour le ticket, j’y réponds dès que j’ai un moment !

Hello,

J’ai créé un autre ticket, ce jour :
▻https://github.com/seenthis/hebergement/issues/30

Et un autre :
▻https://github.com/seenthis/seenthis_squelettes/issues/295

Oui, y-a un ticket squelette, oui, je suis allé lire le code PHP.

Les initiés, pouvez-vous me donner vos avis ?

En gros :

1) seenthis fonctionne avec un webcron, qui s’exécute quand qq’un consulte, cette consultation peut se retrouver très lente en conséquence, plusieurs secondes. Est-il possible de décider de déporter ce webcron dans un vrai cron ?

2) J’étudie, sur le serveur de future prod, les lenteurs mariadb (slow log), et la première lenteur, c’est la construction du fil personnel, qui construit des requêtes à coup de « sql_in ». Avec nos vieux comptes, cela construit des in avec plusieurs centaines d’ID. La seconde lenteur, c’est l’update sur spip_syndic, et là, j’ai l’impression qu’on tombe sur une vraie difficulté, grosse table avec des millions d’enregistrements, et plusieurs index complexes.

Pouvez-vous me faire des retours sur ces sujets SVP ?

Pas accès à la base de données, alors je sais pas trop pour spip_syndic.

À priori, c’est utilisé pour les comptes alimentés par des flux RSS, je ne vois pas pour quoi d’autre ce serait utilisé. Et en plus c’est censé de déconnecter automatiquement au bout d’un certain temps, pour éviter d’avoir des zombies qu’on garde pendant des années.

Du coup, c’est spip_syndic, ou spip_syndic_articles qui a des millions d’enregistrements ?

Si c’est spip_syndic_articles qui est monstrueux, est-ce qu’on ne pourrait pas effacer les anciennes entrées au bout d’un moment, vu que de toute façon sur Seenthis on transforme ce qu’on récupère via les flux RSS en billets Seenthis « normaux » ?

Tu sais que je peux te créer un accès ssh ? :-)

1) le cron est asynchrone, il ne devrait pas avoir d’impact pour les visiteurs du site cf ▻https://programmer.spip.net/Fonctionnement-du-cron ; on doit pouvoir le désactiver et le brancher sur un cron système, à discuter dans le ticket :)

2) ça me rappelle ce ticket ▻https://github.com/seenthis/seenthis_squelettes/issues/159

Concernant la table spip_syndic si ma lecture du code est bonne, elle contient les urls des sites référencés dans les posts. Mais bon, je ne fais que maintenir, je n’ai pas participé à la création du bouzin :p

Ça me contrarie ce que tu me dis sur le cron asynchrone. J’ai des lenteurs qd il se déclenche, apparemment, mais il se peut que ce soit pour une autre raison, donc, que la page s’affiche lentement...

J’ai lu le ticket que tu as indiqué. Les requêtes en l’état sont contre performantes, même si elles fonctionnent bien. Elles pourraient fonctionner mieux. Ceci dit, s’il y avait 10 ou 100 fois plus de trafic, on serait face à de grosses difficultés pour la montée en charge.

Je mets en pause mon profiling pour repasser sur l’installation de manticore. Faut que j’avance sur le nouveau serveur.

N’empêche que je n’ai pas encore réussi à identifier le coupable des lenteurs à la publication. C’est frustrant.