News for hackers. Stuff that matters.
Re:Tornado 2.2 released by alexhaefner on Monday January 30, 2012 @02:58PM (#3530392)
Can anyone here speak to Tornado.websocket? What's the performance like? How could you load balance with torando.websocket? Is it production ready?

Congrats on the release!

Re:Tornado 2.2 released by peterbe on Monday January 30, 2012 @04:41PM (#3530755)
Few people seem to use it directly. Most people are writing production systems with the Tornadio2 wrapper (https://github.com/MrJoes/tornadio2) or sockjs-tornado (https://github.com/MrJoes/sockjs-tornado)

Load balancing is usually done with HAProxy I hear.

Re:Tornado 2.2 released by stuartk on Monday January 30, 2012 @06:17PM (#3531038)
I'm currently creating a product using the Tornadio2 wrapper. The developer Serge is actively developing, and is very helpful.

HAProxy is often used for load balancing websockets as it supports tcp proxies.

There is a tcp module for nginx that can be compiled in at https://github.com/yaoweibin/nginx_tcp_proxy_module

Re:Tornado 2.2 released by jrussbowman on Monday January 30, 2012 @05:53PM (#3530974)
I will second this. I originally deployed chatfor.us with tornadio and then moved to sockjs-tornado and found both extremely easy to implement. I use ha proxy for that app. Unscatter.com doesn't use web sockets and I use nginx as the proxy load balancer for it.
Re:Tornado 2.2 released by majke on Thursday February 02, 2012 @06:36AM (#3542293)
SockJS-tornado can be hosted via HAProxy. If you don't need native websockets, sockjs will work behind any sticky-sessions-aware loadbalancer using comet fallbacks.
Re:Tornado 2.2 released by csytan on Monday January 30, 2012 @02:42PM (#3530314)
Congrats!

I've been using Tornado for over a year now and am impressed with how active Ben has been in improving it. I'm especially happy with the addition of this simple but important feature: "Template errors now generate better stack traces."

Re:Tornado 2.2 released by emehrkay on Monday January 30, 2012 @03:07PM (#3530433)
Tornado has definitely taught me to keep my templates as dumb as possible. Most of the time my errors are me trying to access values that doesnt exist
Re:Tornado 2.2 released by crcsmnky on Monday January 30, 2012 @03:57PM (#3530620)
For the folks out there using Tornado in production, what database (if any) are you using it with? Are you using an async interface to your database (assuming one is available)?
Re:Tornado 2.2 released by Maascamp on Monday January 30, 2012 @07:11PM (#3531163)
For Postgres there's Momoko http://momoko.61924.nl/ which is really quite nice. If you're using MySQL you have a few options including patching MySQLdb as explained by chartio (http://chart.io/blog/2011/06/10/making-mysql-queries-asynchr...). I followed the chartio approach and added in some async cursors to fit in better with the tornado database module. Pretty straightforward stuff.
Re:Tornado 2.2 released by jrussbowman on Monday January 30, 2012 @05:50PM (#3530964)
I use mongodb with bit.ly's asyncmongo.

I honestly was a bit frustrated with it from a development standpoint because of all the callbacks. Just felt like spaghetti code. Since I have started applying tornado.gen its been pretty effective.

Asyncmongo may not fit all use cases though. As I understand it it can be difficult to deal with paging potentially based off of what I have read in the issues on the github repo. Also last I checked it doesn't support tailable cursors.

One thing to note is that with friendfeed they did synchronous requests to MySQL and their thought was you should make sure the requests responses are quick enough that blocking is not an issue. After working hard to do asynchronous requests I'm now of the opinion I should have taken their word for it.

Re:Tornado 2.2 released by Yaggo on Tuesday January 31, 2012 @01:54AM (#3532188)
I benchmarked pymongo vs. asyncmongo and found no performance gain (or even negative gain) with the latter unless making relatively heavy/slow queries. So, the asynch spaghetti is not worth of it in most cases, just like the authors experienced with MySQL.
Re:Tornado 2.2 released by peterbe on Monday January 30, 2012 @05:28PM (#3530911)
I use MongoDB and to do that I use MongoKit. Works really well. I also use Redis for the caching (note: not as a database)

For both Mongo and Redis I use the sync libraries. So far, I don't have any slow queries that would require me to async them.

Re:Tornado 2.2 released by salem on Monday January 30, 2012 @09:30PM (#3531541)
Before the Twisted/Tornado bridge existed, I made a rest-api for my DB in Twisted. There are a bunch of good async DB clients implemented for Twisted Python. It also made for good MVC separation.
Re:Tornado 2.2 released by giulivo on Monday January 30, 2012 @05:44PM (#3530949)
MongoDB with asyncmongo
Re:Tornado 2.2 released by phatbyte on Tuesday January 31, 2012 @06:49AM (#3532849)
Wow, I'm really impressed with Tornado. I'm learning node.js at the moment, but I've been working with Python/Django as well, so I will definitely consider this for my project.

Any benchmarks between node.js and Tornado btw ?

Re:Tornado 2.2 released by km3k on Monday January 30, 2012 @03:51PM (#3530600)
At first I thought this was going to be about a different Tornado. http://borkhuis.home.xs4all.nl/vxworks/vxworks.html
Re:Tornado 2.2 released by craigyk on Monday January 30, 2012 @11:16PM (#3531822)
How would people recommend doing async file IO w/ tornado? I was using Tornado until I needed to write a server to handle very large file uploads at which point I switched to Node.js + CoffeeScript.
Re:Tornado 2.2 released by wisty on Tuesday January 31, 2012 @12:34AM (#3532015)
You could just use URL plumbing and nginx for the uploader. This looks promising: http://didipkerabat.com/post/2724838963/nginx-file-upload-an...
Re:Tornado 2.2 released by LeafStorm on Monday January 30, 2012 @03:10PM (#3530443)
Once I wrote a server that speaks the Redis protocol using Tornado's TCP networking tools. It was probably the nicest API for asynchronous networking without coroutines that I have ever seen.