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.
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?
[^] # Re: Temps de traitement
Posté par j_m . En réponse au message Nombre de Consommateurs par queue. É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?
Scalabilite en fonction du nombre de thread
www.warski.org/blog