Question

I have just begun to look at tornado and asynchronous web servers. In many examples for tornado, longer requests are handled by something like:

1. make a call to tornado webserver
2. tornado makes async web call to an api
3. let tornado keep taking requests while callback waits to be called
4. handle response in callback. server to user.

So for hypothetical purposes say users are making a request to tornado server at /retrive. /retrieve will make a request to an internal api myapi.com/retrieve_posts_for_user_id/ or w/e. the api request could take a second to run while getting requests, then when it finally returns tornado servers up the response. First of all is this flow the ‘normal’ way to use tornado? Many of the code examples online would suggest so.

Secondly, (this is where my mind is starting to get boggled) assuming that the above flow is the standard flow, should myapi.com be asyncronous? If its not async and the requests can take seconds apiece wouldn’t it create the same bottleneck a blocking server would? Perhaps an example of a normal use case for tornado or any async would help to shed some light on this issue? Thank you.

Answer 1

Yes, as I understand your question, that is a normal use-case for Tornado.

If all requests to your Tornado server would make requests to myapi.com, and myapi.com is blocking, then yes, myapi.com would still be the bottleneck. However, if only some requests have to be handled by myapi.com, then Tornado would still be a win, as it can keep handling such requests while waiting for responses for the requests to myapi.com. But regardless, if myapi.com can’t handle the load, then putting a Tornado server in front of it won’t magically fix that. The difference is that your Tornado server will still be able to respond to requests even when myapi.com is busy.