Quand et comment utiliser Tornado? Quand est-ce inutile?


84

Ok, Tornado est non bloquant et assez rapide et il peut gérer facilement beaucoup de demandes permanentes.

Mais je suppose que ce n'est pas une solution miracle et que si nous exécutons aveuglément Django ou tout autre site avec Tornado, cela ne donnera aucune amélioration des performances.

Je n'ai pas pu trouver d'explication complète à ce sujet, alors je la pose ici:

  • Quand utiliser Tornado?
  • Quand est-ce inutile?
  • Lors de son utilisation, que faut-il prendre en compte?
  • Comment pouvons-nous rendre un site inefficace en utilisant Tornado?
  • Il y a un serveur et un webframework. Quand devrions-nous utiliser le framework et quand pouvons-nous le remplacer par un autre?

Réponses:


45

Il y a un serveur et un webframework. Quand devrions-nous utiliser le framework et quand pouvons-nous le remplacer par un autre?

Cette distinction est un peu floue. Si vous ne servez que des pages statiques, vous utiliserez l'un des serveurs rapides comme lighthttpd. Sinon, la plupart des serveurs offrent une complexité variable de cadre pour développer des applications Web. Tornado est un bon framework Web. Twisted est encore plus capable et est considéré comme un bon cadre de réseau. Il prend en charge de nombreux protocoles.

Tornado et Twisted sont des frameworks qui prennent en charge le développement d'applications web / réseau asynchrones et non bloquants.

Quand utiliser Tornado? Quand est-ce inutile? Lors de son utilisation, que faut-il prendre en compte?

De par sa nature même, les E / S asynchrones / non bloquantes fonctionnent très bien lorsqu'elles sont intensives en E / S et pas en calcul. La plupart des applications Web / réseau conviennent bien à ce modèle. Si votre application nécessite une tâche intensive de calcul, elle doit être déléguée à un autre service capable de mieux la gérer. Alors que Tornado / Twisted peut faire le travail de serveur Web, répondre aux demandes Web.

Comment pouvons-nous rendre un site inefficace en utilisant Tornado?

  1. Faites n'importe quelle tâche de calcul intensif
  2. Introduire les opérations de blocage

Mais je suppose que ce n'est pas une solution miracle et que si nous exécutons aveuglément Django ou tout autre site avec Tornado, cela ne donnera aucune amélioration des performances.

Les performances sont généralement une caractéristique de l'architecture complète des applications Web. Vous pouvez réduire les performances avec la plupart des frameworks Web, si l'application n'est pas conçue correctement. Pensez à la mise en cache, à l'équilibrage de charge, etc.

Tornado et Twisted offrent des performances raisonnables et sont parfaits pour créer des applications Web performantes. Vous pouvez consulter les témoignages de tordu et de tornade pour voir de quoi ils sont capables.


1
Merci pour la réponse. Je veux juste clarifier certains points: Puis-je utiliser Flask ou Django bihind Tornado et obtenir tous ses avantages (si je ne fais aucune tâche de campagne) sans changer le code de l'application?
Vladimir Sidorenko

Si oui, quelle sera la différence par rapport à courir dire avec flup? Merci.
Vladimir Sidorenko

Je souhaite analyser les flux RSS dans l'application Tornado. Considérez-vous cela assez intensif en calcul?
Susheel Javadi

6

Je suis désolé d'avoir répondu à une vieille question, mais je suis tombé sur celle-ci et je me suis demandé pourquoi elle n'avait pas plus de réponses. Pour répondre à la question de Bart J:

Je souhaite analyser les flux RSS dans l'application Tornado. Considérez-vous cela assez intensif en calcul?

Eh bien, cela dépend du type d'analyse que vous faites et du matériel :) Le temps est long, donc si votre application met plus d'une demi-seconde à répondre, cela semblera lent - profilez votre application.

La clé des systèmes rapides est une excellente architecture, pas tant les spécificités que le framework que vous utilisez (Twisted, Tornado, Apache + PHP). Tornado a un style de traitement asynchrone et c'est vraiment ce à quoi cela revient à mon avis. Node.js, Twisted et Yaws sont des exemples d'autres serveurs Web asynchrones qui évoluent très bien en raison d'une approche légère et d'un style de traitement asynchrone.

Donc:

Quand utiliser Tornado?

Quand est-ce inutile?

Tornado est bon pour gérer de nombreuses connexions, car il peut répondre à un client entrant, distribuer un gestionnaire de requêtes et ne pas penser à ce client tant que le rappel de résultat n'est pas poussé dans la file d'attente d'événements. Donc, pour cette qualité spécifique, Tornado doit être utilisé lorsque vous souhaitez bien évoluer lorsque vous gérez de nombreuses demandes. Le traitement asynchrone facilite le découplage fonctionnel et l'accès aux données sans partage. Cela balance très bien avec un design apatride comme REST ou d'autres architectures orientées services . Vous n'avez pas non plus à gérer autant de threads ou de processus de génération avec la surcharge inhérente et vous pouvez éviter une partie des problèmes de verrouillage / IPC.

Tornado ne fera pas beaucoup de différence, en revanche, si votre backend et / ou votre magasin de données prend beaucoup de temps pour traiter les demandes. Il permet notamment de réaliser des conceptions simultanées et des services Web. L'architecture simultanée facilite la mise à l'échelle de votre conception et maintient le couplage bas. C'est du moins mon expérience avec Tornado.


Que faire si vous avez peu d'opérations dans votre service qui sont intensives en calcul (disons> 1 s)? Est-il encore possible d'effectuer ce type de traitement de manière non bloquante?
tigeronk2

@ tigeronk2 Oui, mais vous devrez exécuter le calcul dans un autre thread / processus.
Morten Jensen

Ou exécutez potentiellement le processus intensif comme un autre service pour obtenir l'évolutivité et la séparation avec une petite surcharge par rapport à la gestion d'un autre processus. Regardez le lien Architectures orientées services.
Tyeth

L'analyse RSS n'est presque par définition pas un traitement lourd, à moins que vous ne le fassiez très mal.
tripleee
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.