Le web est un grand endroit maintenant. Nous devons supporter des milliers de clients à la fois, et voici Tornado. Tornado est un framework web Python et une bibliothèque réseau asynchrone, développée à l’origine chez FriendFreed.
Tornado utilise le réseau non bloquant-io. Grâce à cela, il peut gérer des milliers de connexions actives au serveur. C’est un sauveur pour les applications où de longs polling et un grand nombre de connexions actives sont maintenus.
Tornado n’est pas comme la plupart des frameworks Python. Il n’est pas basé sur WSGI, bien qu’il supporte certaines fonctionnalités de WSGI en utilisant le module `tornado.wsgi`. Il utilise une conception de boucle d’événement qui rend l’exécution des requêtes Tornado plus rapide.
Qu’est-ce qu’un programme synchrone ?
Une fonction se bloque, effectue son calcul et revient, une fois terminé . Une fonction peut se bloquer pour de nombreuses raisons : E/S réseau, E/S disque, mutex, etc.
Les performances d’une application dépendent de l’efficacité avec laquelle l’application utilise les cycles CPU, c’est pourquoi les déclarations/appels bloquants doivent être pris au sérieux. Considérez les fonctions de hachage de mot de passe comme bcrypt, qui par conception utilisent des centaines de millisecondes de temps CPU, bien plus qu’un accès typique au réseau ou au disque. Comme le CPU n’est pas inactif, il n’est pas nécessaire d’opter pour des fonctions asynchrones.
Une fonction peut être bloquante dans un, et non bloquante dans d’autres. Dans le contexte de Tornado, nous considérons généralement le blocage dû aux E/S réseau et au disque, bien que tous les types de blocage doivent être minimisés.
Qu’est-ce qu’un programme asynchrone ?
1) Architecture monofilaire :
Cela signifie qu’il ne peut pas faire des tâches centrées sur le calcul de manière parallèle.
2) Concurrence E/S :
Il peut transmettre les tâches E/S au système d’exploitation et continuer à la tâche suivante pour réaliser le parallélisme.
3) epoll/ kqueue:
Souligne la construction liée au système qui permet à une application d’obtenir des événements sur un descripteur de fichier ou des tâches spécifiques d’E/S.
4) Boucle d’événements:
Elle utilise epoll ou kqueue pour vérifier si un événement s’est produit, et exécute le callback qui attend ces événements réseau.
Cadre Web asynchrone vs synchrone :
Dans le cas du modèle synchrone, chaque demande ou tâche est transférée à un thread ou à un routage, et lorsqu’elle se termine, le résultat est remis à l’appelant. Ici, la gestion des choses est facile, mais la création de nouveaux threads est trop de surcharge.
D’autre part, dans le cadre asynchrone, comme Node.js, il y a un modèle à un seul thread, donc très moins de surcharge, mais il a la complexité.
Imaginons des milliers de demandes qui arrivent et un serveur utilise la boucle d’événement et le callback. Maintenant, jusqu’à ce que la demande soit traitée, il doit stocker et gérer efficacement l’état de cette demande pour mapper le résultat du callback au client réel.
Node.js vs Tornado
La plupart de ces points de comparaison sont liés au langage de programmation réel et non au framework :
- Node.js a un gros avantage que toutes ses bibliothèques sont Async. En Python, il y a beaucoup de paquets disponibles, mais très peu d’entre eux sont asynchrones
- Comme Node.js est un runtime JavaScript, et que nous pouvons utiliser JS pour le front-end et le back-end, les développeurs peuvent garder une seule base de code et partager la même bibliothèque utilitaire
- Le moteur V8 de Google rend Node.js plus rapide que Tornado. Mais beaucoup de bibliothèques Python sont écrites en C et peuvent être des alternatives plus rapides.
Un exemple simple de ‘Hello World’
CODE : https://gist.github.com/velotiotech/b4d91554b739f2487bf6131ac65ec06d.js
Note : Cet exemple n’utilise aucune fonctionnalité asynchrone.
Utilisant le module AsyncHTTPClient, nous pouvons faire un appel REST de manière asynchrone.
CODE : https://gist.github.com/velotiotech/5fe63eb5fd6cf3af9bf353c2fd3b4ca7.js
Comme vous pouvez le voir `yield http_client.fetch(url)` s’exécutera comme une coroutine.
Exemple complexe de Tornado Async
Veuillez jeter un coup d’œil au gestionnaire de requête asynchrone.
WebSockets Using Tornado:
Tornado a un package intégré pour les WebSockets qui peut être facilement utilisé avec des coroutines pour obtenir la simultanéité, voici un exemple:
CODE : https://gist.github.com/velotiotech/34d0a0e0ecd57818ae1db1697c075777.js
On peut utiliser une application client WebSocket pour se connecter au serveur, le message peut être un entier quelconque. Après traitement, le client reçoit le résultat si l’entier est premier ou non.
Voici un autre exemple des fonctionnalités asynchrones réelles de Tornado. Beaucoup le trouveront similaire à la Goroutine et aux canaux de Golang.
Dans cet exemple, nous pouvons démarrer un ou des travailleurs et ils écouteront la ‘tornado.queue’. Cette queue est asynchrone et très similaire au paquet asyncio.
CODE : https://gist.github.com/velotiotech/1477131948ca23879167df0281726d02.js
Conclusion
1) Les frameworks asynchrones ne sont pas très utiles lorsque la plupart des calculs sont centrés sur le CPU et non sur les E/S.
2) En raison d’un seul thread par modèle de noyau et de boucle d’événement, il peut gérer des milliers de connexions client actives.
3) Beaucoup disent que Django est trop gros, Flask est trop petit, et Tornado est juste parfait 🙂
.