L’asynchronisme en programmation<span class="wtr-time-wrap after-title"><span class="wtr-time-number">10</span> min read</span>
asynchronisme vs threading

L’asynchronisme en programmation10 min read

Dans cet article, on va attaquer un concept très complexe et bien souvent mal compris par les nouveaux programmeurs. L’asynchronisme, dans cet article vous allez apprendre comment fonctionne l’asynchronisme ainsi que ses avantages. Avant toute choses, qu’est ce que c’est l’asynchronisme en programmation ?

C’est quoi l’asynchronisme ?

Et oui, c’est la question de base. Avant même de comprendre ses avantages ou comment la mettre en place, voyons ce que c’est l’asynchronisme.

Pour ça, on va devoir comparer le fonctionnement ‘classique’ d’un programme et le fonctionnement lorsque l’on utilise l’asynchronisme. Vous l’aurez donc compris , l’asynchronisme c’est une façon de programmer. Et ce n’est pas la façon généralement utilisée.

Le système de threading

Les programmes plus classiques qui doivent gérer de la concurrence c’est à dire exécuter du code en même temps utilisent un système de threading. On compte dans ces programmes les serveurs web, les serveurs de jeux ou globalement tout ce qui as besoin d’exécuter plusieurs choses en même temps.

Donc ces programmes dans leur système classique utilisent le threading. Qu’est ce que c’est exactement ?

Et bien le threading c’est le fait de créer plusieurs instances d’un même programme. Concrètement , pour un serveur web, à chaque fois qu’un utilisateur fait une requête, une instance ce lanceras et géreras la requête. On peux voir les threads comme une mini exécution de votre programme. De ce fait si vous avez 100 threads disponible, chacun prendras 1% de la puissance totale du serveur web.

Pourquoi as-t-on besoin des threads ?

C’est vrai ça , pourquoi on utilise ça ? On pourrais simplement lancer un serveur web a 100% la puissance et gérer les requêtes ? Et bien non.

Mais pourquoi ? Et bien car si vous faites ça , votre serveur sera d’une lenteur astronomique. Cela peux sembler illogique et laissez moi vous expliquer pourquoi cette approche ralentirais votre serveur.

Vous le savez peut-être, les programmes devant gérer des serveurs exécutent beaucoup d’actions externes au programme appelés aussi IO. Une action externe c’est pas exemple une requête à la base de donnée. Pendant que la base de donnée fait ses recherches, le serveur attends patiemment la réponse.

Donc sur un système de threading il n’y a pas de soucis, seule le thread est immobilisé, mais si aucun thread n’existe, et bien pour chaque requête, le serveur web attendras la réponse des IO et donc ne géreras pas les autre requêtes en attendant. Ce qui va générer un temps de réponse astronomiquement long.

Les threads permettent de pallier à ça en découpant votre programme en plusieurs instances indépendantes et ce à chaque requête d’un utilisateur. Ainsi, pendant une phase d’IO, le thread va attendre mais les autres threads continueront leur travail. Cette approche permets de régler le problème du temps d’attente mais elle crée un gros défaut.

Le défaut des threads

Vous vous doutez que si on as inventé une autre approche , c’est que celle-ci possède des défauts. En même temps en programmation comme dans tout le reste, rien n’es jamais parfait.

Comme je vous l’ai expliqué, les threads permettent de créer plusieurs instances de votre programme et ainsi éviter à celui-ci d’avoir un temps d’attente pour chaque requête astronomique à cause des IO. Néanmoins le temps d’attente existe toujours.

Ou se trouve ce temps d’attente maintenant ?

Et bien j’ai dis qu’a chaque fois qu’une requête était faite, le programme lançait un thread. Néanmoins ce thread as besoin d’attendre la réponse de l’IO pour s’exécuter et se fermer. Donc à chaque requête un thread est crée. Puis il dois attendre l’IO, répondre et enfin se fermer.

Vous l’aurez compris, on évite les temps d’attente gigantesque mais c’est loin d’être optimisé. Chaque thread passe une bonne partie de son temps à attendre. Voyons maintenant comment pallier à ce problème grâce à l’asynchronisme.

Comment ça fonctionne l’asynchronisme

Bon, maintenant que l’on as vu le système classique et ses défauts, comparons le avec le système asynchrone.

Ce schéma illustre parfaitement bien la différence entre asynchronisme et threading. Ici le threading c’est le “parralel” et l’asynchrone le “concurrent”.

Dans le premier cas, on voit que notre programme exécute deux instances en même temps. Donc comme on l’as vu, les temps d’attente existent mais sont répartis sur les deux threads.

A l’inverse, le modèle 2 n’as qu’un seul thread et exécute les tâches de manière concurrente. C’est à dire qu’il va passer d’une tâche à l’autre des qu’il y a un temps d’attente.

L’exemple du serveur web

Pour reprendre le même exemple qu’avec le threading, voyons comment se comporte l’asynchronisme sur un serveur web.

Comme je l’ai dis, on as un seul thread contrairement au threading qui utilise plusieurs threads.

Donc on se retrouve avec le même problème qu’avant ?

Bien sûre que non, sinon on n’utiliserait pas l’asynchronisme. Ce qui règle le problème qu’on as vu au début c’est le système de concurrence. Des qu’une requête as un temps d’attente, le programme en exécute une autre et reviens à celle de base lorsque le temps d’attente est finit.

Ainsi votre programme ne possède plus aucun temps d’attente et est 100% optimisé, génial non ?

schéma de l'event loop de node js
schéma de l’event loop de node js

Voici l’évent loop de node js (Node JS est un langage de programmation serveur basé sur javascript utilisant l’asynchronisme). On peux voir qu’une boucle est utilisée. Cette boucle va en fait prendre les requêtes entrantes et les exécuter jusqu’à ce qu’un IO bloque. Dans ce cas l’évent loop exécute d’autres actions et reprends les précédentes une fois l’IO terminée.

Ce système de l’extérieur semble parfait. Rappelez vous de ce que j’ai dis toute à l’heure , “rien n’es jamais parfait”. Voyons maintenant les défauts des systèmes asynchrones.

Les défauts du système asynchrone

Je ne vais pas vous mentir, l’asynchronisme c’est très difficile à mettre en place. En fait, si le modèle de threading est si utilisé, c’est parce qu’il es bien plus simple à mettre en place que le système asynchrone.

Concrètement on obtiens un système avec aucun temps morts, le système est optimisé à l’extrême. Mais ça demande d’avoir un code très optimisé parce que sinon vous risquez d’avoir des problèmes…

Les erreurs dans le code

Si votre code contiens des erreurs comme une parcelle de code bloquant c’est à dire qui va empêcher le programme de lancer une autre tâche pendant l’IO. Vous allez avoir un programme d’une lenteur absolue. En effet , en créant involontairement du code bloquant , on as un serveur web à un seul thread et de l’attente, donc c’est extrêmement lent.

Vous l’aurez compris le vrai défaut de l’asynchronisme c’est la difficulté d’apprentissage. Vous devez apprendre à écrire du code de manière asynchrone. C’est loin d’être insurmontable mais ça demande du travail et ce n’est pas forcément super intuitif quand on code en threading depuis plusieurs années.

Les raisons d’utiliser l’asynchronisme

Maintenant que vous avez-vu le fonctionnement de l’asynchronisme. Nous allons voir pourquoi vous-devriez l’utiliser dans votre programme.

C’est une question assez compliquée. Ce n’est pas un hasard si la majorité des programmes utilisent le système de threading, c’est bien documenté et globalement c’est la norme. Néanmoins de plus en plus de grandes entreprises utilisent node JS.

Par exemple wall Mart utilisent Node JS et ont indubitablement augmenté la performance de leur serveur grâce à cette technologie. Netflix sont passés d’une architecture JAVA monolythique à une architecture asynchrone toujours sous Node JS. Ils ont augmenté leur taux de requête par secondes de 60% et réduis leur temps de boot après mise à jour de 97%.

Alors pourquoi tout le monde n’utilise pas node JS ?

Et bien parce que c’est complexe à mettre en place. Utiliser Node JS ou tout autre système asynchrone demande d’apprendre de nouvelles technologies et méthodes et c’est globalement difficile voir impossible de migrer d’un système de threading à un système asynchrone. Pour la simple et bonne raison que la plus-part des langages asynchrone ne gère pas le threading et vise-versa.

Quelles sont les bonnes raisons d’utiliser l’asynchronisme ?

Si vous avez besoin que votre application aie de bonnes performances. L’asynchronisme semble être une bonne solution. Il y auras sûrement un petit temps d’apprentissage avant de maîtriser cette technologie. Mais en quelques jours ou semaine vous serez capable d’utiliser ce système et d’améliorer les capacités de votre programme.

Si à l’inverse, vous désirez un système stable, classique bien qu’un peu plus lent. Vous devriez utiliser une architecture classique de threading. Si en plus de cela vous maîtrisez déjà cette méthode et ne désirez pas apprendre une nouvelle technologie, partez sur le threading.

En conclusion

Je vous remercie d’avoir lu cet article et j’espère vous avoir aidé. En conclusion je dirais que si vous êtes intéresses par les nouvelles technologies particulièrement sur le web. Vous devriez vous intéresser à l’asynchronisme et à Node JS. A l’inverse, si vous ne vous préoccupez pas des performances , avez déjà un système en production ou n’avez pas le temps d’apprendre, vous devriez conserver une architecture de threading.

Si cet article vous as plu, vous pouvez vous abonner à ma newsletter pour recevoir le guide GRATUIT Ultime pour bien débuter la programmation

Vous abonner à notre newsletter

* champ requis

Si cet article vous as plu, je vous invite à me laisser un commentaire, je me ferai un plaisir de vous répondre. Si vous avez une question ou une requête de tutoriel , vous pouvez m’envoyer un mail à cet adresse : leblogducodeur@gmail.com

Je vous souhaite une bonne journée, au plaisir de vous voir sur mon blog !

Laisser un commentaire

Fermer le menu
×
×

Panier