Tornado 2.1 released

Post by candl » Thu, Sep 22, 2011, 11:26 AM UTC

zeemonkee wrote: post #8

rjd wrote: post #2

90% made up my mind to use Tornado for several upcoming projects, would love to hear some comments (good or bad) from anyone thats used it or using it.

I've noticed that Tornado comes with its own MySQL wrapper, however I'm concerned it might have blocking issues. Does anyone have experience with using this ? Also, what do people use for form validation with Tornado ?

Post by wulczer » Thu, Sep 22, 2011, 12:27 PM UTC

wisty wrote: post #12

zeemonkee wrote: post #8

Earlier quoted context omitted.

I've noticed that Tornado comes with its own MySQL wrapper, however I'm concerned it might have blocking issues. Does anyone have experience with using this ? Also, what do people use for form validation with Tornado ?

The theory is, you shouldn't need async database access. If your database is a bottleneck, you are screwed, regardless of how your app layer is scaling. The main advantage of async is not blocking if you call an external web API.

Post by wulczer » Thu, Sep 22, 2011, 12:42 PM UTC

dchest wrote: post #14

wulczer wrote: post #13

Earlier quoted context omitted.

That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests. Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from b…

From this thread https://groups.google.com/forum/#!topic/python-tornado/mgj18... (posting here because Google Groups sometimes require login): 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 serv…

Post by wisty » Thu, Sep 22, 2011, 12:51 PM UTC

wulczer wrote: post #15

dchest wrote: post #14

Earlier quoted context omitted.

From this thread https://groups.google.com/forum/#!topic/python-tornado/mgj18... (posting here because Google Groups sometimes require login): 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 serv…

Erm, so if things are fast it doesn't matter and if things are slow you should write a whole new service, put a HTTP interface into it and use that? Not sure I buy that :) Disclaimer: I wrote an async DB module for Twisted/PostgreSQL and it did not turn out to be all that complex.

Post by peterbe » Thu, Sep 22, 2011, 2:03 PM UTC

oxfordus wrote: post #9

Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that: www.site.com/controller/action/params/?vars -> would route to -> class controller(requestHandler): def get_action(self, *params, **vars): #do something self.write(response) def post_action2(self, *params, **vars): #.... and so on ....

  class LoginHandler(RequestHandler):
      def get(self):
          self.render('login.html')
      def post(self):
          self.set_secure_cookie(self.get_argument('username'))
        self.redirect('/')