Lamento haber respondido una vieja pregunta, pero encontré esta y me pregunté por qué no tenía más respuestas. Para responder a la pregunta de Bart J:
Me gustaría analizar las fuentes RSS en la aplicación Tornado. ¿Lo consideraría bastante intensivo en computación?
Bueno, eso depende del tipo de análisis que estés haciendo y del hardware :) Mucho tiempo es mucho tiempo, así que si tu aplicación tarda más de medio segundo en responder, parecerá lenta: crea un perfil de tu aplicación.
La clave para los sistemas rápidos es una gran arquitectura, no tanto los detalles como, por ejemplo, qué marco estás usando (Twisted, Tornado, Apache + PHP). Tornado tiene un estilo de procesamiento asincrónico y eso es realmente a lo que se reduce, en mi opinión. Node.js, Twisted y Yaws son ejemplos de otros servidores web asincrónicos que escalan muy bien debido a un enfoque ligero y un estilo de procesamiento asincrónico.
Entonces:
¿Cuándo se debe utilizar Tornado?
¿Cuándo es inútil?
Tornado es bueno para manejar muchas conexiones, ya que puede responder a un cliente entrante, enviar un controlador de solicitud y no pensar en ese cliente hasta que la devolución de llamada de resultado se inserte en la cola de eventos. Entonces, para esa calidad específica, Tornado debe usarse cuando desee escalar bien al manejar muchas solicitudes. El procesamiento asíncrono facilita el desacoplamiento funcional y el acceso a datos sin compartir nada. Eso va muy bien con el diseño sin estado como REST u otras arquitecturas orientadas a servicios . Tampoco tiene que lidiar tanto con los subprocesos o procesos de generación con la sobrecarga inherente y puede evitar algunos de los problemas de bloqueo / IPC.
Tornado no hará mucha diferencia, por otro lado, si su backend y / o almacén de datos tarda mucho en procesar las solicitudes. Ayuda a realizar diseños concurrentes y servicios web en particular. La arquitectura concurrente hace que sea más fácil escalar su diseño y mantener el acoplamiento bajo. Esa es mi experiencia con Tornado al menos.