Seb35
commented
6 years ago Voilà, c’est fait. Il y a le détail que tous les processus envoient en même temps sur la sortie standard et ça rend lui-ci difficilement lisible, il faudra ouvrir une issue séparée si vraiment ça gêne car ça rentre plutôt dans la problématique de la gestion d’erreurs en contexte de production intensive.
Noter que par rapport à l’intitulé originel de cette issue, le code du travail met désormais 2h20, notamment par l’optimisation des appels à SQLite (8 par texte au maximum au lieu d’un par article et section) et l’ajout du mécanisme de cache hiérarchique de sections (ne pas recalculer une section qui n’est pas modifiée d’une version à l’autre). La résolution de cette issue est donc moins pressante qu’auparavant, mais c’est toujours ça de gagné dans une optique de production en masse.
L’export est l’étape qui prend le plus de temps (jusqu’à 85h pour le code du travail qui totalise 1600 versions). Dans une optique de production journalière, il pourrait être calculé plusieurs codes/textes de loi en même temps.
Cela peut se faire relativement facilement avec la bibliothèque multiprocessing et sa classe Pool ou une autre bibliothèque (je connais celle-ci mais ne suis pas particulièrement connaisseur de l’écosystème Python).
Un point à gérer est que SQLite ne semble pas spécialement apprécier les accès concurrents (j’ai essayé de lancer deux AL en ligne de commande et SQLite m’a jeté, possiblement il faut donc gérer les verrous en écriture).