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?

Answer 1

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.