Tornado 1.2 • Hacker News Board

Re: Tornado 1.2

#31

Post by ntoshev » Mon, Feb 21, 2011, 9:58 AM UTC

clojurerocks wrote: post #15

Whats the difference between tornado and node.js? Besides the obvious that they are developed in different languages.

node.js is asynchronous from the ground up, Tornado is generally synchronous with the exception of http client and server. So, Tornado is less pure, but you can use any of the Python libraries as they are. Node.js is pure, even disk i/o is asynchronous, but there are much fewer libraries.

Tornado also wraps Facebook API and has authentication with Facebook, Google, Twitter and everyone else.

Re: Tornado 1.2

#32

Post by wisty » Mon, Feb 21, 2011, 10:26 AM UTC

pjscott wrote: post #19

epynonymous wrote: post #18

Earlier quoted context omitted.

traditional web servers like apache 2, create processes to handle web applications that are developed in say ruby or python (e.g. phusion passenger, mod_wsgi). from what i understand (correct me if i'm wrong) these processes inherit large overhead in terms of having to load large numbers of libraries so memory usage is quite wasteful.

Shared libraries are just that: shared. They get memory-mapped, and the code is shared between processes. When a program has many threads open, something similar happens: the code is shared between the threads, but they get different stacks. Those stacks are a problem if you're spawning tens of thousands of threads, one for each connection you have open concurrently. You may find yourself running out of memory, or at…

IIRC, another thing which keeps processes open is database access.

I'm not sure, but I think that with Apache + Django, you get something like: Apache gets request, gives it to Django, Django asks MySQL for a value, waits, waits, waits (taking up lots of memory, but not too much CPU, but your host charges for RAM), waits a little more, gets a value from MySQL, puts it in a template, hands the response to Apache, which then sends the response to the client.

Re: Tornado 1.2

#33

Post by nailer » Mon, Feb 21, 2011, 10:37 AM UTC

agotterer wrote: post #14

MartinMond wrote: post #2

So is anyone big using Tornado in production? I expected the development to stall with the buyout of Friendfeed

bit.ly uses it in production

Yeah, I was talking to Hilary Mason at FOWA and she mentioned this.

ImEveryone (my own site) uses it to, but we're not quite bitly sized.

Re: Tornado 1.2

#34

Post by statictype » Mon, Feb 21, 2011, 12:37 PM UTC

kqueue wrote: post #28

I don't know how programmers can convince themselves that a framework based on callbacks (event driven) is a good idea.

As opposed to a framework based on....?

Re: Tornado 1.2

#35

Post by kqueue » Mon, Feb 21, 2011, 5:05 PM UTC

statictype wrote: post #34

kqueue wrote: post #28

I don't know how programmers can convince themselves that a framework based on callbacks (event driven) is a good idea.

As opposed to a framework based on....?

Based on coroutines or threads?

Re: Tornado 1.2

#36

Post by Semiapies » Mon, Feb 21, 2011, 10:04 PM UTC

I see references to fixing problems on Windows, but there's no mention of Windows support or installation, nor does the hello-world example run (I get the same failed import on the fcntl module that I always have, even after upgrading).

Does it run under Cygwin?

Re: Tornado 1.2

#37

Post by statictype » Tue, Feb 22, 2011, 12:08 AM UTC

kqueue wrote: post #35

statictype wrote: post #34

Earlier quoted context omitted.

As opposed to a framework based on....?

Based on coroutines or threads?

Aren't events generally cleaner/easier to use than threads? And python doesn't even have true coroutines, does it?

Re: Tornado 1.2

#38

Post by kqueue » Tue, Feb 22, 2011, 5:41 PM UTC

statictype wrote: post #37

kqueue wrote: post #35

Earlier quoted context omitted.

Based on coroutines or threads?

Aren't events generally cleaner/easier to use than threads? And python doesn't even have true coroutines, does it?

Event driven development is the worst kind of programming because of the extensive use of callbacks and state maintenance/tracking. You never know the control flow by reading the source.

You have to maintain state all the time and keep track of inconsistent/impossible states.

That to me is not cleaner or easier.

I work in one of the big corps, and it never fails, event driven servers tend to be way more buggy.

Python out of the box doesn't have coroutines but you can always use gevent for that.

Python threads are real pthreads, now they are not optimal and should not be used in high load servers, because pthreads are not that light weight when you are running 10k of them. Creating servers based on python threads is as clean as coroutine threads but slower. Hence, coroutines are always favorable over them.

Re: Tornado 1.2

#39

Post by statictype » Wed, Feb 23, 2011, 3:01 AM UTC

kqueue wrote: post #38

statictype wrote: post #37

Earlier quoted context omitted.

Aren't events generally cleaner/easier to use than threads? And python doesn't even have true coroutines, does it?

Event driven development is the worst kind of programming because of the extensive use of callbacks and state maintenance/tracking. You never know the control flow by reading the source. You have to maintain state all the time and keep track of inconsistent/impossible states. That to me is not cleaner or easier. I work in one of the big corps, and it never fails, event driven servers tend to be way more buggy. Python…

That's interesting. The conventional wisdom I've seen and read is that multi-threaded servers are generally more buggy and harder to reason about than using a single select loop with callbacks. Callbacks are more difficult to maintain state with, but they don't have race conditions and locking issues.

I agree that if you can get coroutines in your language, then perhaps that's the ideal path to take.