Quando e come utilizzare Tornado? Quando è inutile?


84

Ok, Tornado è non bloccante e abbastanza veloce e può gestire facilmente molte richieste permanenti.

Ma immagino che non sia un proiettile d'argento e se gestiamo ciecamente basato su Django o qualsiasi altro sito con Tornado non darà alcun aumento delle prestazioni.

Non sono riuscito a trovare una spiegazione completa di questo, quindi lo chiedo qui:

  • Quando dovrebbe essere usato Tornado?
  • Quando è inutile?
  • Quando lo si utilizza, cosa si dovrebbe tenere in considerazione?
  • Come possiamo rendere un sito inefficiente utilizzando Tornado?
  • C'è un server e un webframework. Quando dovremmo usare framework e quando possiamo sostituirlo con un altro?

Risposte:


45

C'è un server e un webframework. Quando dovremmo usare framework e quando possiamo sostituirlo con un altro?

Questa distinzione è un po 'sfocata. Se stai servendo solo pagine statiche, useresti uno dei server veloci come lighthttpd. Altrimenti, la maggior parte dei server fornisce una complessità variabile del framework per sviluppare applicazioni web. Tornado è un buon framework web. Twisted è ancora più capace ed è considerato un buon framework di rete. Supporta molti protocolli.

Tornado e Twisted sono framework che forniscono supporto per lo sviluppo di applicazioni web / di rete asincrone e non bloccanti.

Quando dovrebbe essere usato Tornado? Quando è inutile? Quando lo si utilizza, cosa si dovrebbe tenere in considerazione?

Per sua natura, l'I / O asincrono / non bloccante funziona alla grande quando è intensivo di I / O e non di calcolo. La maggior parte delle applicazioni web / di rete si adatta bene a questo modello. Se l'applicazione richiede l'esecuzione di determinate attività computazionali complesse, è necessario delegarla a un altro servizio in grado di gestirle meglio. Mentre Tornado / Twisted può svolgere il lavoro di server web, rispondendo alle richieste web.

Come possiamo rendere un sito inefficiente utilizzando Tornado?

  1. Esegui qualsiasi attività computazionale intensiva
  2. Introduci operazioni di blocco

Ma immagino che non sia un proiettile d'argento e se gestiamo ciecamente basato su Django o qualsiasi altro sito con Tornado non darà alcun aumento delle prestazioni.

Le prestazioni sono generalmente una caratteristica dell'architettura completa dell'applicazione web. È possibile ridurre le prestazioni con la maggior parte dei framework Web, se l'applicazione non è progettata correttamente. Pensa al caching, al bilanciamento del carico, ecc.

Tornado e Twisted forniscono prestazioni ragionevoli e sono utili per la creazione di applicazioni web performanti. Puoi controllare le testimonianze di Twisted e Tornado per vedere di cosa sono capaci.


1
Grazie per la risposta. Voglio solo chiarire alcuni punti: posso usare Flask o Django dietro Tornado e ottenere tutti i suoi vantaggi (se non eseguo attività camputazionali) senza modificare il codice dell'applicazione?
Vladimir Sidorenko

Se sì, quale sarà la differenza rispetto alla corsa diciamo con il flup? Grazie.
Vladimir Sidorenko

Vorrei analizzare i feed RSS nell'applicazione Tornado. Lo considereresti abbastanza intensivo dal punto di vista computazionale?
Susheel Javadi,

6

Mi dispiace per aver risposto a una vecchia domanda, ma mi sono imbattuto in questa e mi sono chiesto perché non avesse più risposte. Per rispondere alla domanda di Bart J:

Vorrei analizzare i feed RSS nell'applicazione Tornado. Lo considereresti abbastanza intensivo dal punto di vista computazionale?

Dipende dal tipo di analisi che stai eseguendo e dall'hardware :) Molto tempo è molto tempo, quindi se la tua app impiega più di mezzo secondo per rispondere, sembrerà lenta: profila la tua app.

La chiave per i sistemi veloci è una grande architettura, non tanto le specifiche quanto ad esempio il framework che stai utilizzando (Twisted, Tornado, Apache + PHP). Tornado ha uno stile di elaborazione asincrono e questo è davvero ciò a cui si riduce a mio parere. Node.js, Twisted e Yaws sono esempi di altri server web asincroni che scalano molto bene grazie a un approccio leggero e allo stile di elaborazione asincrono.

Così:

Quando dovrebbe essere usato Tornado?

Quando è inutile?

Tornado è utile per gestire molte connessioni, poiché può rispondere a un client in entrata, inviare un gestore di richieste e non pensare a quel client finché il callback dei risultati non viene inserito nella coda degli eventi. Quindi, per quella qualità specifica, Tornado dovrebbe essere usato quando vuoi scalare bene quando gestisci molte richieste. L'elaborazione asincrona facilita il disaccoppiamento funzionale e l'accesso ai dati senza condivisione. Funziona molto bene con il design senza stato come REST o altre architetture orientate ai servizi . Inoltre, non devi occuparti così tanto della generazione di thread o processi con l'overhead intrinseco e puoi risparmiare alcuni dei problemi di blocco / IPC.

Tornado non farà molta differenza, d'altra parte, se il tuo backend e / o archivio dati impiega molto tempo per elaborare le richieste. Aiuta a realizzare progetti simultanei e servizi Web in particolare. L'architettura simultanea semplifica la scalabilità del progetto e mantiene basso l'accoppiamento. Questa è almeno la mia esperienza con Tornado.


Cosa succede se nel tuo servizio sono presenti poche operazioni che richiedono un alto livello di calcolo (diciamo> 1 secondo)? È ancora possibile eseguire quel tipo di elaborazione in modo non bloccante?
tigeronk2

@ tigeronk2 Sì, ma dovrai eseguire il calcolo in un altro thread / processo.
Morten Jensen

O potenzialmente eseguire il processo intensivo come un altro servizio per ottenere scalabilità e separazione con un piccolo sovraccarico rispetto alla gestione di un altro processo. Guarda il collegamento alle architetture orientate ai servizi.
Tyeth

L'analisi degli RSS non è quasi per definizione un'elaborazione pesante, a meno che tu non lo stia facendo in modo molto sbagliato.
tripleee
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.