Projet

Général

Profil

Bug #22355

le remapping des statuts sur changement d'un workflow est parfois trop long

Ajouté par Benjamin Dauvergne il y a environ 6 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
07 mars 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Voir #22259, il y a 7293 demandes, on fait un update suivi d'un commit pour chaque demande, sur du disque rotatif on est à minimum 10 ms de latence et à Montpellier qui n'a pas des foudres de guerre comme serveurs certainement plus, soit minimum 70 secondes pour le remapping.

Fred suggère de faire le remapping en dehors de la requête en mettant le formulaire dans un statut maintenance (statut qui n'existe pas actuellement).

Il serait aussi possible d'accélérer la mise à jour en faisant tout cela dans une unique transaction (mais on finira par trouver une instance avec trop de demandes plus tard), à noter quand même qu'une erreur en cours de migration pourrait laisser les formulaires dans un état intermédiaire (je me demande d'ailleurs où ça en est actuellement à Montpellier sur ce formulaire...) ce qui me laisse penser qu'une transaction serait vraiment nécessaire (en plus de la suggestion de Fred).


Demandes liées

Lié à w.c.s. - Development #38579: Mapping de workflow en mode postgresqlFermé17 décembre 2019

Actions

Historique

#2

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

  • Description mis à jour (diff)
#3

Mis à jour par Frédéric Péters il y a environ 6 ans

Je viens (enfin!) de regarder le code et il y a deux temps au remapping :

  • la modification des colonnes status_id des tables du formdata et de ses évolutions, c'est workflow_status_remapping_submit et très simplement, il faudrait juste du code particulier quand on est en mode SQL, pour faire ça à base de UPDATE sur l'ensemble des lignes ; (workflow_status_remapping_submit).
  • la mise à jour des autorisations d'accès (rebuild_security), là c'est a priori moins évident de réduire le nombre de requêtes.
#4

Mis à jour par Thomas Noël il y a environ 6 ans

Et donc, dans un premier temps, faire :

  • la modification des colonnes status_id des tables du formdata et de ses évolutions

lors du submit lui-même (synchrone, avec transaction et plantage possible) ; et

  • la mise à jour des autorisations d'accès (rebuild_security), là c'est a priori moins évident de réduire le nombre de requêtes.

lors d'un afterjob (n'est pas si urgent, on peut survivre à une situation à les demandes n'ont pas de "security" à jour à mon sens, mais je peux me tromper)

#5

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

Oui le rebuild_security est idempotent, on peut foirer recommencer on finira par converger.

Par contre sur la première partie j'ai vraiment l'impression que là ou ça a foiré. les statuts sont en vrac et difficilement récupérable (en vrai je suis très inquiet pour Montpellier, mélange d'anciens et de nouveaux statuts), et oui utiliser UPDATE est la bonne solution, mais c'est peut-être plus de code que de simplement faire en sorte de pouvoir faire un BEGIN/COMMIT en évitant que store() fasse un conn.close() (paramètre close_connection=False?).

#6

Mis à jour par Frédéric Péters il y a environ 6 ans

C'est plus de code mais c'est une question de perf aussi, ne pas charger tous les formdata.

#7

Mis à jour par Frédéric Péters il y a presque 4 ans

#8

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Nouveau à Fermé

Je ferme au profit de #38579 pas la peine de garder deux tickets pour dire la même chose.

Formats disponibles : Atom PDF