3 ms·

It seems like blocking calls to data sources (the database, memcache, etc) would screw with a lot of the benefits of running the framework asynchronously. If yo

It seems like blocking calls to data sources (the database, memcache, etc) would screw with a lot of the benefits of running the framework asynchronously. If your Tornado processes freeze while making synchronous backend requests, you're gonna need a lot of them, which probably kills a lot of the value. Now all we need are async data clients that tie into the Tornado event loop, and a clean way to yield control back and forth (perhaps with coroutines - http://www.python.org/dev/peps/pep-0342/ http://www.python.org/dev/peps/pep-0342/). Unfortunately, I don't think there are any async Python mysql clients (PHP has one now - http://www.scribd.com/doc/7588165/mysqlnd-Asynchronous-Queries-and-more http://www.scribd.com/doc/7588165/mysqlnd-Asynchronous-Queri...) A web app written like that would run like it's on fire. The event loop would just roll through everything asynchronously. You could even automatically batch together data calls across http requests to make things easier on the data tier.

DenisM 17y ago
The browser-webserver delay resulting from long polling is much larger the frontend-backend delay. I think there is at least an order of magnitude difference there, hence an order of magnitude reduction is the amount of idle state kept on the server.
- RoboTeddy 17y ago
  Yeah, I agree. For long-polling apps it seems like Tornado gives you a huge advantage. For other web apps though, the frontend-backend delay is comparatively more important, because usually there's a load balancer or reverse proxy in charge of buffering up data arriving from distant/laggy browser connections and hitting the web application server with it all at once.
extension 17y ago
If you go with an evented architecture like this, you have to use it for pretty much all I/O or the whole thing falls apart. Lack of drivers and protocols has been a large barrier to adoption.

DenisM 17y ago

The browser-webserver delay resulting from long polling is much larger the frontend-backend delay. I think there is at least an order of magnitude difference there, hence an order of magnitude reduction is the amount of idle state kept on the server.

RoboTeddy 17y ago
Yeah, I agree. For long-polling apps it seems like Tornado gives you a huge advantage. For other web apps though, the frontend-backend delay is comparatively more important, because usually there's a load balancer or reverse proxy in charge of buffering up data arriving from distant/laggy browser connections and hitting the web application server with it all at once.

extension 17y ago

If you go with an evented architecture like this, you have to use it for pretty much all I/O or the whole thing falls apart. Lack of drivers and protocols has been a large barrier to adoption.