Discussion :

[Koudou]

Bonjour à tous,

J'ai une question de débutant sur les connexions réseau.

Je comprends le principe des IO non bloquantes traitées par un thread plutôt que d'ouvrir un thread par client. Mais que se passe-t-il dans le cas d'un serveur qui effectue des tâches longues ? Par exemple si un serveur met 2 secondes à répondre à une requête cela veut dire que le serveur mettra 20 secondes pour répondre au dernier client si 10 clients se connectent simultanément ?

D'ailleurs où en est-on de la guerre "1 thread/client" vs "1 thread/tous" ? A une époque la tendance était de dire qu'un thread par client c'était beaucoup trop lourd à gérer, puis (notamment dans le livre de B. Goetz) on a dit que finalement les threads n'étaient pas un problème pour les machines modernes qui étaient taillées pour ça.

Merci pour vos réponses.

[thelvin]

Hello,

quand tu fais des IO non bloquantes, tu utilises un nombre limité de threads dédiés à répondre au client. Cette limite peut être 1 thread max si tu fais des essais et constate que cela répond bien à ta charge attendue. Et ça peut être 15 threads max, ou 50, ou 23 ou ce que tu veux.

Ce qui est important en IO non bloquante, c'est que les threads qui font le boulot ne soient pas constamment bloqués en attente qu'une ressource soit dispo pour leur fournir des données ou leur permettre d'en envoyer. A la place c'est le fait qu'une telle ressource vient de fournir de la dispo, qui signale qu'un thread doit venir bosser dessus maintenant. Personne a jamais dit que les threads qui font le boulot, ils doivent être 1.

C'est en principe évident qu'en multi-cœur, ça sera forcément moins efficace de se limiter à moins de threads que de cœurs. Sauf qu'en réalité, assez souvent le système gère bien assez d'autres threads à côté pour occuper les cœurs. Sauf qu'en général ces autres threads sont rarement actifs suffisamment en même temps pour occuper réellement les cœurs. Donc avoir plusieurs threads, c'est rarement une mauvaise idée. C'est juste qu'il faut quand même éviter d'avoir des dizaines de pools de 50 threads.

[Logan Mauzaize]

Je comprends le principe des IO non bloquantes traitées par un thread plutôt que d'ouvrir un thread par client.

Ce n'est vraiment le principe mais une résultante. Le principe même c'est de pouvoir continuer à travailler plutôt que d'attendre. Cela permet de faire plus de choses avec moins de threads.

Mais que se passe-t-il dans le cas d'un serveur qui effectue des tâches longues ?

Cela dépend de quel type de tâche et si les choses sont bien faites.

Si les choses sont bien faites, toutes les attentes sont gérées et n'impactent pas la durée de la tâche. De ce fait, une tâche peut-être longue mais "interrompu" par des attentes, cependant d'autres tâches peuvent être effectuées pendant ce temps.

S'il s'agit d'une tâche longue sans attente, plusieurs solutions sont possibles. La tâche peut-être découpée de sortes qu'entre deux, le serveur puisse traiter une autre demande. Sinon on peut multiplier le nombre de threads et laisser les couches plus bas niveau (OS, CPU) se charger de distribuer correctement le travail. Dans tous les cas, on peut arriver à saturation mais dans ce cas, l'asynchrone non-bloquant ne change rien au problème.

Par exemple si un serveur met 2 secondes à répondre à une requête cela veut dire que le serveur mettra 20 secondes pour répondre au dernier client si 10 clients se connectent simultanément ?

Tout dépend de comment tu architectures ton application et du type d'opérations effectuées. Si on prend un cas simple de lecture de fichier, il y a de fortes chances qu'avec un seul thread tu puisses servir la totalité des 10 clients en 2 secondes.

D'ailleurs où en est-on de la guerre "1 thread/client" vs "1 thread/tous" ? A une époque la tendance était de dire qu'un thread par client c'était beaucoup trop lourd à gérer, puis (notamment dans le livre de B. Goetz) on a dit que finalement les threads n'étaient pas un problème pour les machines modernes qui étaient taillées pour ça.

Il n'y a pas de "guerre" car la finalité n'est pas toujours la même. En fait tout est question de coût et de compromis.

Le modèle "1 thread-1 client" est plus simple, c'est simplement un modèle séquentiel classique. Il permet de contextualiser facilement ; le début et la fin de la tâche sont bien délimités et situés dans un même flux d'exécution non interrompu. En revanche, il se "scale" très mal. Multiplier les threads nécessite d'augmenter d'autant la mémoire. Et selon le type de traitement, on peut dégrader les performances si le nombre de threads dépassent la capacité du/des CPUs.

Le modèle "few threads-many clients" nécessite plus de gymnastique mentale, de faire très attention aux opérations pour supprimer les attentes (ex : https://en.wikipedia.org/wiki/Non-blocking_algorithm) et découper les tâches (voir Fork/Join framework). De fait de l'asynchronisme, il y a un coût de "context switch" et il peut arriver qu'on accumule très rapidement beaucoup de mémoire car tout le travail des tâches non-terminées s'accumule.
Il faut également noter qu'on doit parfois être très minutieux sur les problèmes de concurrence car on doit découper les tâches qui peuvent s'exécuter sur plusieurs threads ou alors parce que l'ensemble des opérations d'une tâche ne sont pas toujours effectuées sur le même thread.

Dans tous les cas, on est limité à la capacité de calcul et de mémoire à notre disposition.

[Koudou]

Merci pour ces réponses claires et précises.