Development #13617
lancer les tâches de l'agent en parallèle (?)
0%
Description
Aujourd'hui l'agent reçoit un message et lance hobo_notify pour les différents services concernés; dans notre archi SaaS avec un service par VM ça passe inaperçu, dans une archi avec tous les services sur le VM ça peut se sentir; il me semble qu'on pourrait utiliser multiprocessing pour faire digérer le message à plusieurs services en même temps. (pool.imap_unordered(...))
Fichiers
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
À mon avis on peut juste utiliser des threads, tout ce que fait l'agent c'est des fork (et je pense qu'on peut forker dans un thread).
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-worker-run-hobo-processes-in-parallel-13617.patch 0001-worker-run-hobo-processes-in-parallel-13617.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Le gain est significatif en local (même si plutôt ×2 que ×4, pour avoir l'ensemble des deploy/notify exécutés).
Mis à jour par Thomas Noël il y a plus de 7 ans
a priori processes=multiprocessing.cpu_count() c'est la valeur par défaut (et ne rien mettre évitera un crash si NotImplementedError).
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-worker-run-hobo-processes-in-parallel-13617.patch 0001-worker-run-hobo-processes-in-parallel-13617.patch ajouté
En effet, "if processes is None then the number returned by cpu_count() is used".
Mis à jour par Thomas Noël il y a plus de 7 ans
Une nuit plus tard, y'a encore une raison qui m'échappe dans l'utilisation de « pool.imap_unordered » au lieu de « pool.map ».
Mis à jour par Frédéric Péters il y a plus de 7 ans
Sans connaitre les détails d'implémentation derrière, signifier explicitement qu'on se fout de l'ordre des résultats me paraissait une indication qui pouvait être utile.
Mis à jour par Thomas Noël il y a plus de 7 ans
C'est bien possible (et je vais pas lire les implémentations non plus). Ack.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Statut changé de En cours à Résolu (à déployer)
commit f2a9d9170f208f249fcc873a66759916e0ca271f
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Jan 14 15:10:51 2017 +0100
worker: run hobo processes in parallel (#13617)
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
La différence c'est qu'imap_unordered renvoie je pense un générateur avec les résultats dans l'ordre où ils sont produits alors que map renvoie une liste qui respecte l'ordre initial et donc ça attend le dernier résultat avant de renvoyer quelque chose. Si on fait un pipeline de tâches (i.e. plusieurs map en cascade qui se nourissent les uns les autres), chaque map() va bloquer alors que imap_ordered() permettra au pipeline d'avancer en parallèle.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
worker: run hobo processes in parallel (#13617)