Kiedy i jak używać Tornado? Kiedy jest bezużyteczny?


84

Ok, Tornado nie blokuje się, jest dość szybki i może z łatwością obsłużyć wiele stałych żądań.

Ale myślę, że to nie jest srebrna kula i jeśli po prostu ślepo uruchomimy witrynę opartą na Django lub jakąkolwiek inną z Tornado, nie poprawi to wydajności.

Nie mogłem znaleźć wyczerpującego wyjaśnienia tego, więc pytam tutaj:

  • Kiedy należy używać Tornado?
  • Kiedy jest bezużyteczny?
  • Co należy wziąć pod uwagę podczas korzystania z niego?
  • Jak możemy stworzyć nieefektywną witrynę za pomocą Tornado?
  • Jest serwer i platforma internetowa. Kiedy powinniśmy używać frameworka, a kiedy możemy go zastąpić innym?

Odpowiedzi:


45

Jest serwer i platforma internetowa. Kiedy powinniśmy używać frameworka, a kiedy możemy go zastąpić innym?

To rozróżnienie jest nieco rozmyte. Jeśli obsługujesz tylko strony statyczne, użyjesz jednego z szybkich serwerów, takich jak lighthttpd. W przeciwnym razie większość serwerów zapewnia różną złożoność struktury do tworzenia aplikacji internetowych. Tornado to dobry framework sieciowy. Twisted jest jeszcze bardziej wydajny i jest uważany za dobrą strukturę sieciową. Obsługuje wiele protokołów.

Tornado i Twisted to frameworki, które zapewniają obsługę nieblokującego, asynchronicznego tworzenia aplikacji internetowych / sieciowych.

Kiedy należy używać Tornado? Kiedy jest bezużyteczny? Co należy wziąć pod uwagę podczas korzystania z niego?

Ze swej natury asynchroniczne / nieblokujące wejścia / wyjścia działają świetnie, gdy są intensywne we / wy i nie wymagają intensywnych obliczeń. Większość aplikacji internetowych / sieciowych dobrze pasuje do tego modelu. Jeśli Twoja aplikacja wymaga wykonania jakiegoś zadania wymagającego dużej mocy obliczeniowej, musi zostać oddelegowana do innej usługi, która poradzi sobie z tym lepiej. Podczas gdy Tornado / Twisted może wykonywać pracę serwera WWW, odpowiadając na żądania sieciowe.

Jak możemy stworzyć nieefektywną witrynę za pomocą Tornado?

  1. Wykonuj dowolne zadanie wymagające dużej mocy obliczeniowej
  2. Wprowadź operacje blokujące

Ale myślę, że to nie jest srebrna kula i jeśli po prostu ślepo uruchomimy witrynę opartą na Django lub jakąkolwiek inną z Tornado, nie poprawi to wydajności.

Wydajność jest zwykle cechą pełnej architektury aplikacji internetowych. Możesz obniżyć wydajność w przypadku większości struktur internetowych, jeśli aplikacja nie jest poprawnie zaprojektowana. Pomyśl o buforowaniu, równoważeniu obciążenia itp.

Tornado i Twisted zapewniają rozsądną wydajność i są dobre do tworzenia wydajnych aplikacji internetowych. Możesz sprawdzić referencje zarówno skręconych, jak i tornada, aby zobaczyć, do czego są zdolni.


1
Dziękuję za Twoją odpowiedź. Chcę tylko wyjaśnić kilka kwestii: Czy mogę używać Flaska lub Django bihind Tornado i uzyskać wszystkie jego zalety (jeśli nie wykonam żadnych zadań w ramach kampanii) bez zmiany kodu aplikacji?
Vladimir Sidorenko

Jeśli tak - jaka będzie różnica w porównaniu do biegania powiedzmy z flupem? Dziękuję Ci.
Vladimir Sidorenko

Chciałbym przeanalizować kanały RSS w aplikacji Tornado. Czy uznałbyś to za dość wymagające obliczeń?
Susheel Javadi

6

Przepraszam, że odpowiedziałem na stare pytanie, ale natknąłem się na to i zastanawiałem się, dlaczego nie ma więcej odpowiedzi. Aby odpowiedzieć na pytanie Barta J.

Chciałbym przeanalizować kanały RSS w aplikacji Tornado. Czy uznałbyś to za dość wymagające obliczeń?

Cóż, to zależy od tego, jakiego rodzaju parsowanie wykonujesz i na jakim sprzęcie :) Długi czas to dużo czasu, więc jeśli twoja aplikacja potrzebuje więcej niż pół sekundy na odpowiedź, będzie się wydawać powolna - profiluj swoją aplikację.

Kluczem do szybkich systemów jest świetna architektura, nie tyle specyfika, co na przykład używany framework (Twisted, Tornado, Apache + PHP). Tornado ma asynchroniczny styl przetwarzania i moim zdaniem do tego właśnie wiele sprowadza się. Node.js, Twisted i Yaws to przykłady innych asynchronicznych serwerów internetowych, które bardzo dobrze skalują się ze względu na lekkie podejście i asynchroniczny styl przetwarzania.

Więc:

Kiedy należy używać Tornado?

Kiedy jest bezużyteczny?

Tornado jest dobre do obsługi wielu połączeń, ponieważ może odpowiadać klientowi przychodzącemu, wysyłać moduł obsługi żądań i nie myśleć o tym kliencie, dopóki wywołanie zwrotne wyniku nie zostanie umieszczone w kolejce zdarzeń. Dlatego w przypadku tej konkretnej jakości Tornado powinno być używane, gdy chcesz dobrze skalować przy obsłudze wielu żądań. Przetwarzanie asynchroniczne ułatwia funkcjonalne oddzielenie i dostęp do danych bez współdzielenia. To bardzo dobrze się kołysze w przypadku projektowania bezstanowego, takiego jak REST lub inne architektury zorientowane na usługi . Nie musisz też tak bardzo zajmować się tworzeniem wątków lub procesów z nieodłącznym narzutem i możesz zaoszczędzić części problemów z blokowaniem / IPC.

Z drugiej strony Tornado nie zrobi dużej różnicy, jeśli twój backend i / lub magazyn danych zajmuje dużo czasu, aby przetworzyć żądania. W szczególności pomaga w wykonywaniu współbieżnych projektów i usług internetowych. Współbieżna architektura ułatwia skalowanie projektu i utrzymuje niski poziom sprzężenia. Przynajmniej takie jest moje doświadczenie z Tornado.


Co się stanie, jeśli w Twojej usłudze jest niewiele operacji, które wymagają dużej mocy obliczeniowej (powiedzmy> 1 s)? Czy nadal możliwe jest przetwarzanie tego rodzaju w sposób nieblokujący?
tigeronk2

@ tigeronk2 Tak, ale będziesz musiał uruchomić obliczenia w innym wątku / procesie.
Morten Jensen

Lub potencjalnie uruchom intensywny proces jako kolejną usługę, aby osiągnąć skalowalność i separację przy niewielkim narzucie w porównaniu z zarządzaniem innym procesem. Spójrz na łącze Architektury zorientowane na usługi.
Tyeth

Parsowanie RSS prawie z definicji nie jest ciężkim przetwarzaniem, chyba że robisz to bardzo źle.
tripleee
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.