Bug #13964
trigger_jump : jump_and_perform de plus en plus lent...
0%
Description
Avec une petite modif affichant la durée en seconde de chaque jump_and_perform :
0.261832 0.3322 0.447266 0.628633 0.690958 0.848752 0.983511 1.049814 1.217503 1.324358 1.454672 1.568721 1.698665 1.875317 1.926306 2.061496 2.211623 2.256925 2.411533 2.58176 2.682311 2.78373 2.93357 3.066028 3.184602 4.918063 3.496641 3.542648 3.707872 3.759889 5.859611 4.029153 4.22205 4.258166 4.375261 4.556175 4.642614 4.74325 4.959161 5.061929 5.170525 5.179132 ...
Sur un trigger avec 2 ou 300 remontées, cela devient vite bloquant.
Fichiers
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 7 ans
- workflow https://demo.dev.au-quotidien.com/backoffice/workflows/82/ (trigger "jump")
- demandes : https://demo.dev.au-quotidien.com/backoffice/management/jump/
Script :
import datetime
from wcs.formdef import FormDef
from wcs.wf.jump import jump_and_perform
for formdata in FormDef.get(247).data_class().select():
print 'jump_and_perform', formdata, 'in',
d1 = datetime.datetime.now()
jump_and_perform(formdata, '2')
print (datetime.datetime.now() - d1).total_seconds()
Résultat non concluant :
$ sudo -u wcs-au-quotidien wcsctl -f /etc/wcs/wcs-au-quotidien.cfg runscript --vhost=demo.dev.au-quotidien.com /tmp/jumps.py jump_and_perform <Jump 'jump #247-14' id:14> in 0.07793 jump_and_perform <Jump 'jump #247-3' id:3> in 0.050058 jump_and_perform <Jump 'jump #247-2' id:2> in 0.049923 jump_and_perform <Jump 'jump #247-18' id:18> in 0.049959 jump_and_perform <Jump 'jump #247-16' id:16> in 0.049923 jump_and_perform <Jump 'jump #247-12' id:12> in 0.049931 jump_and_perform <Jump 'jump #247-11' id:11> in 0.050702 jump_and_perform <Jump 'jump #247-8' id:8> in 0.091539 jump_and_perform <Jump 'jump #247-5' id:5> in 0.050019 jump_and_perform <Jump 'jump #247-7' id:7> in 0.050075 jump_and_perform <Jump 'jump #247-19' id:19> in 0.049947 jump_and_perform <Jump 'jump #247-4' id:4> in 0.049988 jump_and_perform <Jump 'jump #247-15' id:15> in 0.049898 jump_and_perform <Jump 'jump #247-10' id:10> in 0.050077 jump_and_perform <Jump 'jump #247-1' id:1> in 0.049962 jump_and_perform <Jump 'jump #247-6' id:6> in 0.050037 jump_and_perform <Jump 'jump #247-13' id:13> in 0.049881 jump_and_perform <Jump 'jump #247-17' id:17> in 0.049995 jump_and_perform <Jump 'jump #247-9' id:9> in 0.049915 jump_and_perform <Jump 'jump #247-20' id:20> in 0.049962
Mis à jour par Thomas Noël il y a plus de 7 ans
En ajoutant une action d'envoi de mail lors du jump (dans https://demo.dev.au-quotidien.com/backoffice/workflows/82/status/2/) :
jump_and_perform <Jump 'jump #247-17' id:17> in 0.231491 jump_and_perform <Jump 'jump #247-6' id:6> in 0.233463 jump_and_perform <Jump 'jump #247-10' id:10> in 0.201663 jump_and_perform <Jump 'jump #247-8' id:8> in 0.223233 jump_and_perform <Jump 'jump #247-3' id:3> in 0.241646 jump_and_perform <Jump 'jump #247-1' id:1> in 0.275075 jump_and_perform <Jump 'jump #247-5' id:5> in 0.266627 jump_and_perform <Jump 'jump #247-12' id:12> in 0.284971 jump_and_perform <Jump 'jump #247-9' id:9> in 0.308302 jump_and_perform <Jump 'jump #247-4' id:4> in 0.350006 jump_and_perform <Jump 'jump #247-18' id:18> in 0.349858 jump_and_perform <Jump 'jump #247-7' id:7> in 0.356918 jump_and_perform <Jump 'jump #247-16' id:16> in 0.368179 jump_and_perform <Jump 'jump #247-11' id:11> in 0.399853 jump_and_perform <Jump 'jump #247-19' id:19> in 0.499192 jump_and_perform <Jump 'jump #247-13' id:13> in 0.450732 jump_and_perform <Jump 'jump #247-2' id:2> in 0.458376 jump_and_perform <Jump 'jump #247-14' id:14> in 0.483356 jump_and_perform <Jump 'jump #247-15' id:15> in 0.633248 jump_and_perform <Jump 'jump #247-20' id:20> in 0.516703
Mis à jour par Thomas Noël il y a plus de 7 ans
Donc, dans le saut que je déclenche avec jump_and_perform(formdata, '2') j'ai ajouté une action d'envoi de mail.
Il semble que cette action prend "de plus en plus de temps".
Je n'ai pas testé toutes les autres actions encore, mais c'est la seule pour laquelle je constate le soucis.
Mis à jour par Thomas Noël il y a plus de 7 ans
Donc cela vient du faire que le publisher a des sources de variable de substitution qui ne cessent de grandir, car trigger_jump ne les mets pas à zéro à chaque nouveau formdata.
SOURCES: [<Jump 'jump #247-5' id:5>] SOURCES: [<Jump 'jump #247-5' id:5>, <Jump 'jump #247-14' id:14>] SOURCES: [<Jump 'jump #247-5' id:5>, <Jump 'jump #247-14' id:14>, <Jump 'jump #247-9' id:9>] ...
Mis à jour par Thomas Noël il y a plus de 7 ans
(pour clarifier l'extrait ci-dessus : Jump/jump est le nom du formulaire, il s'agit donc d'une aggregation de formdata)
Mis à jour par Thomas Noël il y a plus de 7 ans
- Fichier 0001-trigger_jump-reset-substitutions-vars-on-each-formda.patch 0001-trigger_jump-reset-substitutions-vars-on-each-formda.patch ajouté
- Statut changé de Nouveau à En cours
- Assigné à mis à Thomas Noël
- Patch proposed changé de Non à Oui
Une solution un peu sale, mais qui marche.
Mis à jour par Frédéric Péters il y a plus de 7 ans
Il y a même pas besoin de changer la signature, tu peux faire formdata.formdef dans la fonction. À part ça, ça me semble ok. (bien sûr ça serait bien chouette d'avoir des tests autour de cette commande).
Mis à jour par Thomas Noël il y a plus de 7 ans
- Fichier 0001-trigger_jump-reset-substitutions-vars-on-each-formda.patch 0001-trigger_jump-reset-substitutions-vars-on-each-formda.patch ajouté
Voilà, avec du test.
Y'a une partie un peu hardcoded dans le test, qui vise le présent ticket (lors du "# check publisher substitutions vars...").
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Statut changé de En cours à Résolu (à déployer)
L'import de CmdTriggerJumps n'est au final pas utilisé, je l'ai retiré et poussé :
commit 62c0b5bd6276b9f41a0b8c1ba2bf026ebdaf946d
Author: Thomas NOEL <tnoel@entrouvert.com>
Date: Mon Nov 14 18:12:38 2016 +0100
trigger_jumps: reset substitution variables on each formdata (#13964)
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Statut changé de Résolu (à déployer) à Fermé
trigger_jumps: reset substitution variables on each formdata (#13964)