That's why FriendFeed developed Tornado ----- because FriendFeed needs to update Timeline in real time and Comet is the best and most popular way to do it. Since FriendFeed also has a lot of long polling connections to maintain,

it makes sense to choose Tornado.

But we also have to see that Tornado is not a panacea, because Tornado's WEB server is single-threaded,

a Request if the blocking I/O, then the process will always hang, can not accept new Requests,

and can not be Finish is blocking other Requests. Although it is possible to Spawn multiple Tornado processes, too many Spawns can consume a lot of memory resources for something as heavyweight as a process. This feels a lot like PHP's FastCGI process flavor.

So if it is a Request that will block I/O is generally to utilize Tornado's built-in asynchronous HTTP Client

to other dynamic backend to do.

So Tornado in production in front of the general have to wrap a layer of nginx as a reverse proxy, with nginx to do static files and other large data I/O operations. Tornado's I/O time is really too expensive, can not afford to spend on this.

As for your question about Tornado's lack of documentation, I think you can take the time to read Tornado's code.

After all, it's a lightweight framework with not much code, but the comments are very detailed and easy to read.

Remember, code is always the best documentation!

Your adoption is my motivation to move forward,

Remember to praise and adopt, it's not easy to answer questions, help each other,