Is Tornado really non-blocking?

Question

Tornado advertises itself as "a relatively simple, non-blocking web server framework" and was designed to solve the C10k problem. However, looking at their database wrapper, which wraps MySQLdb, I came across the following piece of code:

def _execute(self, cursor, query, parameters):
    try:
        return cursor.execute(query, parameters)
    except OperationalError:
        logging.error("Error connecting to MySQL on %s", self.host)
        self.close()
        raise

As far as I know calls to the MySQLdb, which is built on top of libmysqlclient, are blocking.

Am I right in thinking that a long-running query would render the entire Tornado server unresponsive until it finishes or is there magic on the code?

Solution 1

Yes, absent other measures, the server will wait for the query to finish executing. That does not mean Tornado is not a non-blocking web server.

A "non-blocking web server" doesn't block on network I/O (and may have some provision for disk I/O if it does static file serving). That does not mean you get instant, causality-violating instruction execution in your application.

Doing a database call takes time, just like reading files, formatting strings, processing templates, etc. takes time. Doing any of these things in the same thread as the server's main event loop will prevent the loop from moving on until you're done.

Solution 2

Tornado is non-blocking if you write non-blocking code on the top if it, eg. using asyncmongo and @tornado.web.asynchronous decorator. Tornado as a framework provides tools for that.

Bret Taylor, one of the original authors, writes:

We experimented with different async DB approaches, but settled on synchronous at FriendFeed because generally if our DB queries were backlogging our requests, our backends couldn't scale to the load anyway. Things that were slow enough were abstracted to separate backend services which we fetched asynchronously via the async HTTP module.

It's true that Tornado doesn't include a non-blocking database layer; in fact the database layer is not integral part of the Tornado framework at all, as opposed to e.g. Django's ORM. Yes, Tornado ships with blocking MySQL wrapper because that's what FriendFeed happened to use, but it's more an external library than core functionality. I'm pretty sure most people are using something else for database access.

Solution 3

Tornado is nonblocking,but just limited to some IO operation like read or write to a socket file.

if you want everything in your code nonblocking,you have to design by yourself.but if your code is computation intensively, then nonblocking is meaningless for you. this situation you might use multi-process.

remember one thing nonblocking just mean the server send/receive date won’t blocking. If you can’t make your code nonblocking,then your whole application is someway blocking.

Comments

[zneak]

What do you expect? Non-blocking does not mean "all lines are run concurrently".

[Glenn Maynard]

-1 for accepting a wrong answer; a non-blocking webserver should not block requests due to database access (disk access) for other requests.

[ipartola]

I appreciate the comment, but I believe I accepted the answer that addresses my question: will using the MySQL wrapper make the entire server block. The answer seems to be: yes it will. Tornado does not provide a pool of processes to talk to MySQL, so it blocks. Your answer makes sense as well, but Nicholas was here first.

[ipartola]

Thanks for the quick reply. I take non-blocking to mean that while one request is waiting to be processed, another one is being processed since the web server's operations are asynchronous. In this case though, if 9,999 users are requesting a semi-static page, and one requests a long-running query page, the 9,999 users will have to wait for the one user.

[Nicholas Knight]

You're addressing something you don't fully understand. The Tornado webserver is non-blocking. If you choose to use the Tornado framework's optional thin wrapper around MySQLdb, you can injure the benefits of a non-blocking webserver, but that says absolutely nothing about the webserver itself, which the database module is not a part of.

[Glenn Maynard]

@Nicholas Knight: No, I fully understand what a "non-blocking web server framework" (re-read the OP) means; obviously, you do not.

[Chetan]

So if I want to have non-blocking database access in my web application, how would I achieve that with Tornado?

[user2828701]

You don't. You add more Tornado instances and load balance between them. Your DB queries shouldn't take that long; otherwise, that belies some other design and/or ops problem.

[gaborous]

Or you can also use an async interface with a more concurrent-friendly database like asyncmongo or motor with the MongoDB.

[remort]

Can I achieve a parallel execution of several tasks using python threads somehow ?