Wann und wie benutzt man Tornado? Wann ist es nutzlos?


84

Ok, Tornado ist nicht blockierend und ziemlich schnell und kann viele ständige Anfragen problemlos bearbeiten.

Aber ich denke, es ist keine Silberkugel, und wenn wir Django-basierte oder andere Websites mit Tornado blind betreiben, wird dies keinen Leistungsschub bringen.

Ich konnte keine umfassende Erklärung dafür finden, deshalb frage ich hier:

  • Wann sollte Tornado angewendet werden?
  • Wann ist es nutzlos?
  • Was ist bei der Verwendung zu beachten?
  • Wie können wir mit Tornado ineffiziente Websites erstellen?
  • Es gibt einen Server und ein Webframework. Wann sollten wir Framework verwenden und wann können wir es durch ein anderes ersetzen?

Antworten:


45

Es gibt einen Server und ein Webframework. Wann sollten wir Framework verwenden und wann können wir es durch ein anderes ersetzen?

Diese Unterscheidung ist etwas verschwommen. Wenn Sie nur statische Seiten bereitstellen, würden Sie einen der schnellen Server wie lighthttpd verwenden. Andernfalls bieten die meisten Server eine unterschiedliche Komplexität des Frameworks für die Entwicklung von Webanwendungen. Tornado ist ein gutes Webframework. Twisted ist noch leistungsfähiger und gilt als gutes Netzwerk-Framework. Es unterstützt viele Protokolle.

Tornado und Twisted sind Frameworks, die eine nicht blockierende, asynchrone Entwicklung von Web- / Netzwerkanwendungen unterstützen.

Wann sollte Tornado angewendet werden? Wann ist es nutzlos? Was ist bei der Verwendung zu beachten?

Async / Non-Blocking I / O funktioniert naturgemäß hervorragend, wenn es E / A-intensiv und nicht rechenintensiv ist. Die meisten Web- / Netzwerkanwendungen eignen sich gut für dieses Modell. Wenn Ihre Anwendung bestimmte rechenintensive Aufgaben erfordert, muss sie an einen anderen Dienst delegiert werden, der sie besser handhaben kann. Während Tornado / Twisted die Aufgabe eines Webservers übernehmen kann, reagiert er auf Webanfragen.

Wie können wir mit Tornado ineffiziente Websites erstellen?

  1. Machen Sie eine rechenintensive Aufgabe
  2. Blockierungsvorgänge einführen

Aber ich denke, es ist keine Silberkugel, und wenn wir Django-basierte oder andere Websites mit Tornado blind betreiben, wird dies keinen Leistungsschub bringen.

Die Leistung ist normalerweise ein Merkmal einer vollständigen Webanwendungsarchitektur. Sie können die Leistung mit den meisten Webframeworks verringern, wenn die Anwendung nicht ordnungsgemäß entworfen wurde. Denken Sie an Caching, Load Balancing usw.

Tornado und Twisted bieten eine angemessene Leistung und eignen sich gut zum Erstellen leistungsfähiger Webanwendungen. Sie können die Testimonials für Twisted und Tornado lesen, um zu sehen, wozu sie in der Lage sind.


1
Danke für die Antwort. Ich möchte nur einige Punkte klarstellen: Kann ich Flask oder Django bihind Tornado verwenden und alle Vorteile nutzen (wenn ich keine Kampagnenaufgaben mache), ohne den Anwendungscode zu ändern?
Vladimir Sidorenko

Wenn ja - was ist der Unterschied zum Laufen mit flup? Danke dir.
Vladimir Sidorenko

Ich möchte RSS-Feeds in der Tornado-Anwendung analysieren. Würden Sie das als ziemlich rechenintensiv betrachten?
Susheel Javadi

6

Es tut mir leid, dass ich eine alte Frage beantwortet habe, aber ich bin auf diese gestoßen und habe mich gefragt, warum sie nicht mehr beantwortet wurde. Um Bart Js Frage zu beantworten:

Ich möchte RSS-Feeds in der Tornado-Anwendung analysieren. Würden Sie das als ziemlich rechenintensiv betrachten?

Nun, das hängt davon ab, welche Art von Analyse Sie durchführen und auf welcher Hardware :) Lange Zeit ist eine lange Zeit. Wenn Ihre App also mehr als eine halbe Sekunde braucht, um zu antworten, wird es träge erscheinen - profilieren Sie Ihre App.

Der Schlüssel zu schnellen Systemen ist eine großartige Architektur, nicht so sehr die Besonderheiten als vielmehr das verwendete Framework (Twisted, Tornado, Apache + PHP). Tornado hat einen asynchronen Verarbeitungsstil und genau darauf kommt es meiner Meinung nach an. Node.js, Twisted und Yaws sind Beispiele für andere asynchrone Webserver, die sich aufgrund ihres einfachen Ansatzes und ihres asynchronen Verarbeitungsstils sehr gut skalieren lassen.

So:

Wann sollte Tornado angewendet werden?

Wann ist es nutzlos?

Tornado eignet sich für die Verarbeitung vieler Verbindungen, da es auf einen eingehenden Client antworten, einen Anforderungshandler versenden und nicht an diesen Client denken kann, bis der Ergebnisrückruf in die Ereigniswarteschlange verschoben wird. Für diese spezielle Qualität sollte Tornado verwendet werden, wenn Sie bei der Bearbeitung vieler Anfragen gut skalieren möchten. Die asynchrone Verarbeitung erleichtert die funktionale Entkopplung und den Zugriff auf gemeinsam genutzte Daten. Das passt sehr gut zu staatenlosem Design wie REST oder anderen serviceorientierten Architekturen . Sie müssen sich auch nicht so sehr mit dem Laichen von Threads oder Prozessen mit dem inhärenten Overhead befassen, und Sie können einige der Sperr- / IPC-Probleme sparen.

Tornado macht andererseits keinen großen Unterschied, wenn die Verarbeitung der Anforderungen in Ihrem Backend und / oder Datenspeicher lange dauert. Dies hilft insbesondere bei gleichzeitigen Designs und Webdiensten. Die gleichzeitige Architektur erleichtert die Skalierung Ihres Designs und hält die Kopplung niedrig. Das ist zumindest meine Erfahrung mit Tornado.


Was ist, wenn Sie nur wenige Operationen in Ihrem Dienst haben, die rechenintensiv sind (z. B.> 1 Sek.)? Ist es immer noch möglich, diese Art der Verarbeitung nicht blockierend durchzuführen?
Tigeronk2

@ tigeronk2 Ja, aber Sie müssen die Berechnung in einem anderen Thread / Prozess ausführen.
Morten Jensen

Oder führen Sie den intensiven Prozess möglicherweise als einen anderen Service aus, um Skalierbarkeit und Trennung mit einem geringen Aufwand im Vergleich zur Verwaltung eines anderen Prozesses zu erreichen. Schauen Sie sich den Link Serviceorientierte Architekturen an.
Tyeth

Das Parsen von RSS ist per Definition keine schwere Verarbeitung, es sei denn, Sie machen es sehr, sehr falsch.
Tripleee
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.