When and how to use Tornado? When is it useless?
Question:
Ok, Tornado is non-blocking and quite fast and it can handle a lot of standing requests easily.
But I guess it’s not a silver bullet and if we just blindly run Django-based or any other site with Tornado it won’t give any performance boost.
I couldn’t find comprehensive explanation of this, so I’m asking it here:
- When should Tornado be used?
- When is it useless?
- When using it, what should be taken into account?
- How can we make inefficient site using Tornado?
- There is a server and a webframework.
When should we use framework and when can we replace it with other one?
Answers:
There is a server and a webframework. When should we use framework and when can we replace it with other one?
This distinction is a bit blurry. If you are only serving static pages, you would use one of the fast servers like lighthttpd. Otherwise, most servers provide a varying complexity of framework to develop web applications. Tornado is a good web framework. Twisted is even more capable and is considered a good networking framework. It has support for lot of protocols.
Tornado and Twisted are frameworks that provide support non-blocking, asynchronous web / networking application development.
When should Tornado be used?
When is it useless?
When using it, what should be taken into account?
By its very nature, Async / Non-Blocking I/O works great when it is I/O intensive and not computation intensive. Most web / networking applications suits well for this model. If your application demands certain computational intensive task to be done then it has to be delegated to some other service that can handle it better. While Tornado / Twisted can do the job of web server, responding to web requests.
How can we make inefficient site using Tornado?
- Do any thing computational intensive task
- Introduce blocking operations
But I guess it’s not a silver bullet and if we just blindly run Django-based or any other site with Tornado it won’t give any performance boost.
Performance is usually a characteristic of complete web application architecture. You can bring down the performance with most web frameworks, if the application is not designed properly. Think about caching, load balancing etc.
Tornado and Twisted provide reasonable performance and they are good for building performant web applications. You can check out the testimonials for both twisted and tornado to see what they are capable of.
I’m sorry for answering an old question, but I came across this one and wondered why it didn’t have more answers. To answer Bart J’s question:
I would like to parse RSS feeds in the Tornado application. Would you consider that fairly computationally intensive?
Well that depends on what kind of parsing you’re doing and on what hardware 🙂 Long time is a long time, so if your app takes more than say half a second to respond, it’ll seem sluggish – profile your app.
The key to fast systems is great architecture, not so much the specifics as for instance which framework you’re using (Twisted, Tornado, Apache+PHP). Tornado has an asynchronous processing style and that’s really what a lot of it comes down to in my opinion. Node.js, Twisted and Yaws are examples of other asynchronous web servers that scale very well because of a lightweight approach and asynchronous processing style.
So:
When should Tornado be used?
When is it useless?
Tornado is good for handling a lot of connections, since it can respond to an incoming client, dispatch a request handler and don’t think about that client until the result-callback is pushed on the event queue. So for that specific quality Tornado should be used when you want to scale well when handling a lot of requests.
The async processing facilitates functional decoupling and shared-nothing data access. That swings really well with stateless design like REST or other Service Oriented Architectures. You also don’t have to deal with spawning threads or processes with the inherent overhead so much and you can save some of the locking/IPC trouble.
Tornado won’t make much of a difference, on the other hand, if your backend and/or data store takes a long time to process the requests. It helps to do concurrent designs and Web services in particular. The concurrent architecture makes it easier to scale your design and keep the coupling low. That’s my experience with Tornado at least.
Ok, Tornado is non-blocking and quite fast and it can handle a lot of standing requests easily.
But I guess it’s not a silver bullet and if we just blindly run Django-based or any other site with Tornado it won’t give any performance boost.
I couldn’t find comprehensive explanation of this, so I’m asking it here:
- When should Tornado be used?
- When is it useless?
- When using it, what should be taken into account?
- How can we make inefficient site using Tornado?
- There is a server and a webframework.
When should we use framework and when can we replace it with other one?
There is a server and a webframework. When should we use framework and when can we replace it with other one?
This distinction is a bit blurry. If you are only serving static pages, you would use one of the fast servers like lighthttpd. Otherwise, most servers provide a varying complexity of framework to develop web applications. Tornado is a good web framework. Twisted is even more capable and is considered a good networking framework. It has support for lot of protocols.
Tornado and Twisted are frameworks that provide support non-blocking, asynchronous web / networking application development.
When should Tornado be used?
When is it useless?
When using it, what should be taken into account?
By its very nature, Async / Non-Blocking I/O works great when it is I/O intensive and not computation intensive. Most web / networking applications suits well for this model. If your application demands certain computational intensive task to be done then it has to be delegated to some other service that can handle it better. While Tornado / Twisted can do the job of web server, responding to web requests.
How can we make inefficient site using Tornado?
- Do any thing computational intensive task
- Introduce blocking operations
But I guess it’s not a silver bullet and if we just blindly run Django-based or any other site with Tornado it won’t give any performance boost.
Performance is usually a characteristic of complete web application architecture. You can bring down the performance with most web frameworks, if the application is not designed properly. Think about caching, load balancing etc.
Tornado and Twisted provide reasonable performance and they are good for building performant web applications. You can check out the testimonials for both twisted and tornado to see what they are capable of.
I’m sorry for answering an old question, but I came across this one and wondered why it didn’t have more answers. To answer Bart J’s question:
I would like to parse RSS feeds in the Tornado application. Would you consider that fairly computationally intensive?
Well that depends on what kind of parsing you’re doing and on what hardware 🙂 Long time is a long time, so if your app takes more than say half a second to respond, it’ll seem sluggish – profile your app.
The key to fast systems is great architecture, not so much the specifics as for instance which framework you’re using (Twisted, Tornado, Apache+PHP). Tornado has an asynchronous processing style and that’s really what a lot of it comes down to in my opinion. Node.js, Twisted and Yaws are examples of other asynchronous web servers that scale very well because of a lightweight approach and asynchronous processing style.
So:
When should Tornado be used?
When is it useless?
Tornado is good for handling a lot of connections, since it can respond to an incoming client, dispatch a request handler and don’t think about that client until the result-callback is pushed on the event queue. So for that specific quality Tornado should be used when you want to scale well when handling a lot of requests.
The async processing facilitates functional decoupling and shared-nothing data access. That swings really well with stateless design like REST or other Service Oriented Architectures. You also don’t have to deal with spawning threads or processes with the inherent overhead so much and you can save some of the locking/IPC trouble.
Tornado won’t make much of a difference, on the other hand, if your backend and/or data store takes a long time to process the requests. It helps to do concurrent designs and Web services in particular. The concurrent architecture makes it easier to scale your design and keep the coupling low. That’s my experience with Tornado at least.