Bah du coup ça va dépendre de l'API Rest "finale", si elle est synchrone (requête bloquante) et que le traitement est long la présence de plusieurs worker va permettre de paralléliser les traitements.
Il y a par contre une petite subtilité: si l'API Rest elle-même est mono-traitement avec un lock sur une ressource commune les multiples workers ne vont pas être très utiles.
Par contre si on se focalise sur la partie "Queue", ce sont des systèmes spécifiquement fait pour être consommé par plusieurs workers, c'est la tout le principe: on empile les tâches dans la file d'attente et dès qu'un worker est disponible il dépile une tâche et la traite, laissant les autres tâches prêtes à être affectées au prochain worker disponible.
comment déterminer le nombre optimal et les facteurs déterminants?
J'imagine qu'il y des considérations de latence du réseaux et du nombre de processeurs
C'est la partie compliquée, dans ton cas cela va dépendre de l'api est (distante ?) et des capacités de traitement qu'elle offre principalement.
Ca va dépendre aussi de ton nombre de réquêtes/messages à traiter (une queue avec 200 workers pour 2 messages / heures ce n'est pas très pertinent).
Dans le cas de worker faisant le travail en local ça va dépendre des ressources à disposition versus celles nécessaires pour le traitement.
La latence du réseau peut être un élement moteur en effet, je pense pas qu'il soit prioritaire mais l'augmentation des workers peut compenser la lenteur du réseau si le traitement est déporté comme dans ton cas.
# Temps de traitement
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au message Nombre de Consommateurs par queue. Évalué à 4.
Bah du coup ça va dépendre de l'API Rest "finale", si elle est synchrone (requête bloquante) et que le traitement est long la présence de plusieurs worker va permettre de paralléliser les traitements.
Il y a par contre une petite subtilité: si l'API Rest elle-même est mono-traitement avec un lock sur une ressource commune les multiples workers ne vont pas être très utiles.
Par contre si on se focalise sur la partie "Queue", ce sont des systèmes spécifiquement fait pour être consommé par plusieurs workers, c'est la tout le principe: on empile les tâches dans la file d'attente et dès qu'un worker est disponible il dépile une tâche et la traite, laissant les autres tâches prêtes à être affectées au prochain worker disponible.
C'est la partie compliquée, dans ton cas cela va dépendre de l'api est (distante ?) et des capacités de traitement qu'elle offre principalement.
Ca va dépendre aussi de ton nombre de réquêtes/messages à traiter (une queue avec 200 workers pour 2 messages / heures ce n'est pas très pertinent).
Dans le cas de worker faisant le travail en local ça va dépendre des ressources à disposition versus celles nécessaires pour le traitement.
La latence du réseau peut être un élement moteur en effet, je pense pas qu'il soit prioritaire mais l'augmentation des workers peut compenser la lenteur du réseau si le traitement est déporté comme dans ton cas.