Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tornado: FriendFeed's non-blocking Python web server is now open source

bret.appspot.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#71

Post by riobard »

eggnet wrote: post #63
agazso wrote: post #59

Earlier quoted context omitted.

You guessed right. Context switching is expensive, and the default stack size default is in the megabyte range. So if you want to have 10K connections open, it takes about 10GB memory. You can of course shrink the stack size, but you have to measure your programs stack usage before doing that and it is quite cumbersome. With an event driven architecture you only have to hold the session information per connection in…

I believe this is one of the advantages of 64 bit architectures. That meg of stack size is just a reservation, it's not actually used, unless your thread really needs it. On a 64 bit machine there is plenty of space to allocate.

It doesn't solve the context _switching_ cost.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#72

Post by kingkongrevenge »

riobard wrote: post #71
eggnet wrote: post #63

Earlier quoted context omitted.

I believe this is one of the advantages of 64 bit architectures. That meg of stack size is just a reservation, it's not actually used, unless your thread really needs it. On a 64 bit machine there is plenty of space to allocate.

It doesn't solve the context _switching_ cost.

This just isn't a substantial cost any more. With the latest kernels, thread per connection servers are competitive with event driven servers. This was not true a few years ago.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#73

Post by extension »

Tichy wrote: post #64
kingkongrevenge wrote: post #58

Earlier quoted context omitted.

I don't think threads are slower or less scalable anymore. The OS threading systems have improved a lot over the last four years.

At least if you use a language like Erlang, I suppose. (Although I think that wouldn't be OS threading, but still).

Erlang threads (processes actually), are very different from OS threads. They are extremely lightweight and allow you to do this kind of event driven networking with threaded code.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#74

Post by extension »

RoboTeddy wrote: post #45

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…

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.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#75

Post by extension »

xal wrote: post #49
tiredandempty wrote: post #44

Earlier quoted context omitted.

how about turning this to a full framework? or is there one already?

I'll brainstorm the idea. I have some ideas of how to turn this evented programming into a very natural flow using ruby 1.9.1's fibers.

I've been tinkering with continuation passing web frameworks in Ruby, but haven't had time to really dive into making one. There is plenty of inspirational material out there e.g. Seaside. If you get anywhere, myself and probably others in the community would be interested to hear about it.

http://blog.extension.ws/11/modal_web_experiments

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#76

Post by pwmanagerdied »

jnoller wrote: post #54
TimothyFitz wrote: post #48

Earlier quoted context omitted.

If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.

I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threaded app like a message-passing app and you have a much simpler life. I'm intimately familiar with the limitations of python threads - and right now I'm the maintainer of the multip…

<3 multiprocessing, <3 you.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#77

Post by TimothyFitz »

jnoller wrote: post #54
TimothyFitz wrote: post #48

Earlier quoted context omitted.

If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.

I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threaded app like a message-passing app and you have a much simpler life. I'm intimately familiar with the limitations of python threads - and right now I'm the maintainer of the multip…

I wasn't trying to claim you don't understand python, simply that the only way to be CPU bound on multiple cores with a single python process (as is claimed) is to be running non-pure python code that unlocks the GIL before doing CPU intensive work.
Post reply on HN