Bonjour,
Je récupère une architecture avec des queues pour apporter de l'asynchronicité mais quelques choix me paraissent mystérieux.
Ainsi on crée une dizaine de workers pour lire la queue en parallèle et ces workers ne font que lire les messages de la queue (SQS) et envoyer le contenu vers une api rest. C'est un processus batch sans interaction.
Vous avez une idée de l'avantage d'avoir plusieurs workers? Est-ce qu'une queue sqs répond plus vite si elle est sollicitée par plusieurs connexions simultanées? Ca parait contre intuitif.
Et si il y a un avantage à utiliser plusieurs workers, 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.
Donc en fait mon application marche mais j'aimerai me faire une opinion critique sur les choix opérés.
# Temps de traitement
Posté par -=[ silmaril ]=- (site web personnel) . É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.
[^] # Re: Temps de traitement
Posté par j_m . Évalué à 2.
Du point de vue du systeme qui heberge la queue, il a un overhead a gerer les differentes connexions entrantes. Le scenario optimal devrait etre qu'il ai en permanence juste un thread en attente dans le pool de thread pour juste empecher les temps morts mais pas plus. Apparement la queue SQS scale tres bien jusqu'a une 20 aine de threads sur un node (voire 50 threads si c'est pour envoyer les messages sur la queue) est-ce que c'est le nombre de thread qui permet d'eliminer les temps morts ou bien est-ce qu'il y a une autre magie qui opere?
www.warski.org/blog
[^] # Re: Temps de traitement
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Je pense que tu as mal lu le bench, je ne connais pas SQS qui est apparement un produit amazon
dans tout les cas je ne pense pas qu'il soit très utile de se prendre la tête sur les performances du système de file de message, essaye plutot en priorité de calculer les taux d'usages de tes threads de traitements pour savoir si tu en a besoin d'autant ou de plus
[^] # Re: Temps de traitement
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
En gros il te faut deux indicateurs sur ton monitoring:
Le temps passé par chaque thread de traitement à bosser
La taille de la queue (nombre de message en attente)
Si le premier est faible (et que le second est toujours nul ou presque) => tu as moyen de réduire le nombre de worker
Si le second est élevé et que les workers sont très souvent tous actif => il faut essayer d'augmenter les worker ("essayer" car le travail des worker peut est bloqué par une autre contrainte qui limite tout le système)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.