4 ms·
I had a few issues with Tornado when I tried it (back in February). They pretty much came down to two things: 1. Database queries are not asynchronous. This is
by russell_h 16y ago
I had a few issues with Tornado when I tried it (back in February). They pretty much came down to two things:
1. Database queries are not asynchronous. This is a big deal for most traditional web applications, and pretty much removes any benefit to using Tornado for them. Even for things that rely mostly on HTTP APIs, there's still a decent chance that you'll want to do authentication or something against a database.
2. It was generally lacking a lot of the maturity and handy declarative syntax you can get with frameworks like Django. There was no ORM, form helpers, etc.
That being said, I really like the idea, performance was great and development seemed to be proceeding at a tremendous pace. The whole project is on GitHub and they seemed very willing to accept both bug-fixes and features.
- cookiecaper 16y agoWhy does it need its own ORM and form helpers? Just install SQLAlchemy and WebHelpers, import and use them.
- frognibble 16y agore 1: Bret Taylor addressed db queries in the video on Tornado (the video is on Facebook, but I cannot find the link). If you run more than one instance of Tornado per core and you have a decent load balancer in front of the instances, then short blocking calls to the db work just fine. If your db calls are taking a long time, then it might be better to speed up the queries with caching or query optimization before worrying about async. I like this approach because I prefer writing app logic in a straight line instead of in callbacks. The code is easier to understand and debug.
- paul 16y agoExactly. Async is very important when you're blocking on an external event (such as fetching a page doing doing hanging-GET), but local db or filesystem blocking can most easily be handled by just running more Tornado instances (because they better not be blocking for too long anyway, or else your site is dead).
- joshu 16y agoany recommendations re loadbalancers?
- frognibble 16y agonginx
- timr 16y agohaproxy is brilliant.
- sramov 16y agonginx. And I've heard a bunch of good things about Perlbal, too.
- jfarmer 16y agoYou might be able to do this with decorators in Python, but in Ruby (1.9 or 1.8 w/ the fibers patch) there are libraries that make these calls asynchronous with minimal or no changes to your code, e.g., neverblock. http://www.espace.com.eg/neverblock/ http://www.espace.com.eg/neverblock/
- draegtun 16y agoIn Python i suspect you could use things like Twisted or Multiprocessing (module) here. In Perl there is AnyEvent and luckily CPAN already provides AnyEvent wrappers around pretty much everything! ref: http://search.cpan.org/search?mode=module&query=AnyEvent%3A%3A%2A&complete=1 http://search.cpan.org/search?mode=module&query=AnyEvent... BTW, There is a (fledging but robust) port of Tornado to Perl: http://search.cpan.org/dist/Tatsumaki/ http://search.cpan.org/dist/Tatsumaki/
- jakevoytko 16y agoTornado is great because it's so damn simple. Just a couple of nice little libraries that work well together. It doesn't try to be sneaky about anything, so a glance at the code on Github is usually enough to determine what's going on behind the scenes, and whether or not it's going to be a problem. I've built a few small sites with it, and it's great for experimenting with custom architectures. It doesn't really assume anything about your data or architecture, so you're free to build things on top of it. If you want extra features, they need to come from somewhere else. If you want an integrated solution to knock out a CRUD website in a weekend, you should look at something like Django (which is also fantastic).
- kragen 16y agoThe least time I've taken to knock out a CRUD website with Django is about 45 minutes.
- LiveTheDream 16y agoCan you just use an async db adapter? (I haven't used Tornado)