Un point sur le travail autour des performance de SVP

Équipes maintenance
1

Suite à ce fil @maintenance

plusieurs travaux ont été entrepris pour améliorer les performances de SVP à court terme

Je fais ici un point, et je cloture dans la foulée l’autre sujet, histoire que les gens n’aient pas à lire tout l’historique de la discussion qui devient longue.

A la fin de ce point, 3 sondages auxquels vous êtes invité·es à répondre, mais bien sûr vous pouvez aussi poser des questions et réagir autrement que par le vote.

L’enjeu

Actuellement SVP, le plugin-dist qui permet d’installer automatiquement des plugins en allant les chercher, sur internet (classiquement sur un dépot géré par la communauté, mais potentiellement ailleurs) fonctionne ainsi :

  • tout les 6 heures, il va lire un fichier decrivant les différents paquets proposés par un dépot ; typiquement pour la plupart des installations SPIP il s’agit de ce fichier https://files.spip.net/spip-zone/archives.xml
  • puis il va écrire cela en base de données

Ce qui permet ensuite de faire une recherche de plugin, et de l’installer automatiquement.

Les problèmes

Il y a (au moins) 4 problèmes :

  1. Un problème (relativement) mineur est que le xml décrivant un dépôt n’est pas un vrai xml
  2. d’un point de vue general, il serait sans doute plus pertinent de revoir de fond en comble l’architecture pour éviter ces actualisation de l’ensemble des informations toutes les 6 h. C’est une proposition de @eric_tonton
  3. Sans changer l’architecture actuelle, on constate que le parsing des fichier XML decrivant un depot est couteux en memoire vive, ce qui peut provoquer des fatals sur les petites installations, en plus d’être peu écologique
  4. En dehors même de cela, le fichier du dépôt principal pèse 9 Mo. Cela veut dire que toutes les 6 h, un site SPIP classique telecharge 9 Mo. Certes sur l’ensemble du trafic internet c’est peu, mais tout de meme.

Les propositions à court terme

Les point 0 et 1 ci dessous ne sont pas concernés par ces propositions, car ils nécessitent des refontes majeures. Si des gens le désir, libre à elles / eux d’ouvrir un autre fil de discussion.

Un double travail a été fait à 3 (marcimat, cedric et moi-même) pour améliorer donc les points 2 et 3.

Concernant le point 2, l’emprise mémoire vive

Cedric a revu le parsage des fichiers XML pour diminuer d’un facteur 3.3 environ l’utilisation memoire vive.

Il s’agit de cette MR

A mon sens cette MR est fonctionnelle et peut être reportée sur les branches pour SPIP 4.4 sans souci.

Concernant le point 3, la taille des fichiers XML échangés

Pour gagner à la fois en mémoire et en usage réseau, un travail a été accompli par marcimat et moi même.

L’idée c’est d’avoir plusieurs variantes pour un même dépot.

a. Une variante complète avec TOUTES les informations sur TOUs (ou presque) les paquets (donc TOUs les tags, ou presque) de TOUT les plugins du dépot. C’est en fait la variante qu’on utilise aujourd’hui, mais qui ne devrait servir que pour les sites qui visent justement à lister tout. J’ai écris « presque » car s’il y a plusieurs versions correctives (z) pour une même branche de plugin (x.y) on ne garde que la dernière.
→ https://files.spip.net/spip-zone/archives.xml
b. Une variante plus légère, où l’on supprime les plugins historiques qui utilisent plugin.xml et pas paquet.xml
→ https://files.spip.net/spip-zone/archives.full.xml
c. Une variante encore plus légère où l’on supprime les informations qui ne servent pas à SVP dans son mode par défaut (pour les sites SPIP autres que contrib.spip.net et plugins.spip.net)
→ https://files.spip.net/spip-zone/archives.thin.xml
d. Et surtout des variantes VRAIMENT plus légères, basés sur c, où

La generation de tout cela c’est le « debardeur » qui s’en charge. Et donc c’est cette MR qui améliore les choses.

Et pour la zone cela donne cela, à 13h57

- archives.xml (pas de maj): 9.0MiB — 3602 archives
- archives.full.xml (pas de maj): 7.9MiB — 2997 archives
- archives.thin.xml (maj): 5.4MiB — 2997 archives
- archives.thin.spip_4_4.xml (pas de maj): 1.2MiB — 723 archives

Entre a et d on passe de 9 Mio à 1.2 Mio. Donc un facteur 7.5. Combiné à la MR de cedric, cela ferait un gain potentiel d’un facteur 24 de mémoire vive. Pas rien. De plus une telle architecture assure que le fichier lu ne gonfle pas éternellement, vu que les plugins qui ne sont plus maintenus avec les nouvelles versions de SPIP ne seront plus listés.

On garderait donc
a. Pour plugins.spip.net / contrib.spip.net
b. Non, inutile à priori
c. Pour les sites qui utilisent la constante de compatibilité forcée, donc normalement au bout de peu de temps, les sites en questions désactivent la constante, et repassent sur une version légère
d. Pour les sites en productions courantes, à partir de SPIP 4.4 et uniquement pour les versions déjà sorties (donc pas pour SPIP 5)

Comme vous pouvez le constater, ces variantes sont déjà disponibles sur les sites de la communauté.

Reste donc à ce qu’elles soient EFFECTIVEMENT utilisés par les SPIP qui seront mis à jour à l’avenir.

C’est l’enjeu de cette MR dans SVP, que de chercher par priorité les fichiers les plus léger (pour permettre aux éventuels dépôts autres que communautaires de continuer à fonctionner).

Les questions qui se posent

  • Prend-t-on le risque de déployer les 2 MR en questions sur des SVP pour spip 4.4, en sachant que nous n’avons pas relu intégralement tous les fichiers de depots pour voir si pas d’erreur.
    (A mon sens OUI, mais cela veut dire qu’il faut des gens pour lire attentivement aussi la MR sur le debardeur pour vérifier sa cohérence)
  • Plus prosaïquement, faut-il appeler les variantes par version de SPIP
    • archives.thin.spip_x_y.xml
    • ou bien archives.thin.spip-x.y → ma préférence
    • ou bien archives.thin.spip-vx.y

Sachant qu’on a deja des fichiers https://files.spip.net/spip/archives/spip-v4.4.7.zip. Donc les 2 dernières syntaxes seraient plus cohérentes. Le choix entre le v et le non v étant qu’une branche n’est pas une version précise de SPIP, mais un ensemble de version. C’est à dire que la branche 4.4 contient spip v4.4.0 + spip v4.4.1 + spip v4.4.2 etc. Donc je suis plutôt favorable à ne PAS mettre le v. Mais je n’irais pas me battre la dessus.

Les sondages

Sur la MR de perf memoire

  • Reporter la MR de PERF memoire en 4.4
  • Ne pas reporter la MR de PERF memoire en 4.4
  • Abstention
0 votant

Sur la MR de perf réseau

  • Reporter la MR de PERF réseau en 4.4
  • Ne pas reporter la MR de PERF memoire en 4.4
  • Abstention
0 votant

Sur la nomenclature

  • archives.thin.spip_x_y.xml
  • archives.thin.spip-x.y
  • archives.thin.spip-vx.y
  • Abstention
0 votant
1 « J'aime »
2

Correction: Qui ne servent pas à SVP dans son mode par défaut.

Même archives.spip-x.y sans le .thin pourrait aussi très bien convenir.

1 « J'aime »
3

Effectivement

Effectivement, mais bon j’ai l’impression qu’on se dirige vers on garde tel quel

4

Note importante : avant de reporter, il faut deja relire et valider les MR.

5

Précision sur les sondages : jusqu’à samedi de la semaine prochaine, sauf s’il y a des gros débat. Samedi j’aurais du temps pour appliquer les décisions.

6

En attendant, personne ne semble voir d’intérêt à la version full.xml (sans plugin.xml mais sans autres économie). J’ai donc fait cela remove: version full.xml des depots (11906abe) · Validations · spip-contrib-extensions / debardeur · GitLab

7

juste une petite précision : les SPIP ne téléchargent pas le xml de 9Mo toutes les 6h. Ils envoient une requête avec un If-Modified-Since correspondant à la date du dernier téléchargement.

Donc en théorie le serveur devrait répondre 304 - Not Modidied si le fichier n’a pas été modifié depuis, et on ne devrait re-télécharger le fichier que si il a été modifié depuis.

Cependant sur le serveur je ne vois que des réponses 200 (au lieu de 304), et en investiguant je vois qu’on a une info <last_commit> pour chaque paquet

et donc il la morale c’est qu’à chaque commit sur un plugin qui est présent dans le archives.xml celui-ci change et donc tous les SPIP de la terre le retéléchargent dans les 6h qui viennent.

Il faudrait vérifier ce point aussi donc, si c’est une info utile au site plugins.spip.net et pas à SVP en mode runtime alors il faudrait enlever cette info du fichier archives que l’on distribue aux sites et le réserver au fichier utilisé par plugins.spip.net

8

Ah pardon, j’ai dit une bêtise. Après investigations ce last_commit n’est mis a jour que dans un cas de nouveau zip et donc de mise à jour du archives.xml.

Et je regardais pas les bons logs, j’ai donc bien 8844 hits en 304 sur le serveur pour 5819 hits en 200, ce qui donne un 40% environ de cas de rechargement du fichier xml

9

Cependant sur le serveur je ne vois que des réponses 200 (au lieu de 304), et en investiguant je vois qu’on a une info <last_commit> pour chaque paquet

oui mais attention : ce last-commit correspond au last-commit sur le tag, pas au last commit sur la branch.

Exemple typique

<zip>
<file>spip-contrib-extensions/saisies-222af-saisies-v3.51.8.zip</file>
<size>248625</size>
<date>1617898473</date>
<source>https://git.spip.net/spip-contrib-extensions/saisies.git</source>
<last_commit>2021-04-08 18:14:33</last_commit>
<logo>spip-contrib-extensions/saisies-222af-saisies-v3.51.8.png</logo>
</zip>

On voit que le last commit en question date de 2021, mais clairement j’ai commité sur saisies depuis 2021 :slight_smile:
Je me demande si le problème du If-Modified-Since ne viendrai pas tout simplement du fait que apache utilise la date de création et/ou de modification du fichier et non pas son contenu pour déterminer si ca été modifié.

pourtant si j’en crois le code on ne devrait justement regener le fichier que s’il n’y a pas de modification.

il y a quelquechose qui cloche

10

Ah bah tu as répondu en meme temps que je te disais que je ne comprenais pas. Message croisé donc. Sujet clos ?

11

Super,

merci pour ce travail de fond de dégraissage, et merci pour les explications détaillées, c’est très clair.

Une tite question :

Quid de _DEV_VERSION_SPIP_COMPAT ?

Actuellement, quand une version x ou y sort, on peut dire qu’on veut les plugins compat avec cette version ET avec la version précédente par exemple, ce qui est bien pratique.

Mais là si je comprends bien, il y aurait un seul archive.xml chargé, qui ne contiendrait que les plugins compat avec la version en cours ?

12

Si je ne e trompe pas, c’est traité par :

Et le code perf: lorsqu'on actualiser les dépôts distant, utiliser les variantes des dépôts d'archives par branches spip, ou à défaut thin, si disponibles (!4932) · Requêtes de fusion · spip / svp · GitLab

Par contre, ça imposera certainement aux sites qui posent le define de mettre à jour leur dépôts dans la foulée pour que cela prenne effet.

13

Ah oui merci, ce détail m’avait échappé.

14

Si je ne e trompe pas, c’est traité par :

sur ce point tu ne te trompe pas

Par contre, ça imposera certainement aux sites qui posent le define de mettre à jour leur dépôts dans la foulée pour que cela prenne effet.

Là a priori non, ou en tout cas pas totu le temps.

  1. Lorsqu’on force la constante, en general c’est pour passer d’une version x.y a une version x+1.0. Par exemple de 4.4 à 5.0
  2. Dans ce cas, on a deja les versions compatibles 4.4 dans les infos en base, du fait des précédents passages
  3. Néanmoins il peut y avoir un cas où oui il faudrait forcer : c’est si un passage du cron / de la mise à jour des données en base a eu lieu entre temps : si j’ai bien lu le code de SVP (mais c’était très vite) il semble que SVP nettoie les infos sur les paquets qui ne plus dans le fichier d’archivelist -

Mais bon, d’une manière general, je pense que cette constante de compatibilité ne devrait être utilisé que par les gens qui ont besoin de dev sous spip x+1, ou x+1 n’est pas encore officiellement sorti. Je ne pense pas que ce soit une bonne chose de palrer de cette constante comme solution pour activer les plugins dans un documentation « grand public de mise à jour de SPIP », parceque cela peut laisser penser que cela rend les plugins compatibles, alors que non.

Par ailleurs, à la rigueur le moment où il faudrait forcer la mise à jour de la base c’est plutot au moment même de la montée de version de SPIP : parce que à ce moment là si on passe par exemple de la 4.4 à 5.0 on n’a pas nécessaire. Mais il me semble qu’on devait deja le faire par le passé (souvenir de passage de 3.2 à 4.4). Je propose de tester cela dans un prochain problème dédié spécifiquement à cela, en vu de la préparation de SPIP 5.

15

Suite aux différents votes j’ai donc

16

Merci !

changé les noms des fichiers pour avoir .thin.spip-x.y.xml (marcimat doit déployer encore, il est en déplacement)

Je ne comprends pas, la majorité était pour un nom de fichier sans .xml.

17

Je ne comprends pas, la majorité était pour un nom de fichier sans .xml.

ah non le vote ne concernait pas l’extension xml ou pas (cf mon explication) mais bien la natutre du suffixe AVANT extension. C?est juste une erreur de ma part dans la configuration du vote : j’ai oublié de mettre l’extension. Mais dans l’explication je disais bien que le debat était tiret bas vs tiret du milieu + point.

18

Bon pour l’heure j’attends toujours les validations sur la mr de report de perf memoire et sur la mr de perf reseau

19

Les MR sont mergés et reportés. Je ferme ici donc.