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

Re:Tornado: FriendFeed's non-blocking Python web server is n... by agazso on Friday September 11, 2009 @01:57AM (#816928)

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 memory which can be as low as 4K, therefore you are able to maintain (depending on the complexity of the protocoll) n*100K connections.

The only drawback that you have to write and think your whole program event driven; you write callbacks for each io and timer operation and the control flow won't be clear if you read the program.

[ Parent | on HN ]

Re:Tornado: FriendFeed's non-blocking Python web server is n... by eggnet on Friday September 11, 2009 @03:32AM (#817005)

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.

[ Parent | on HN ]

Re:Tornado: FriendFeed's non-blocking Python web server is n... by agazso on Friday September 11, 2009 @06:22AM (#817111)

Yeah, but why would you waste it for stack space, when you can do an event-driven design, and allocate the resources only when needed?

Anyways, I was talking about C, where the stack is allocated when the thread is created and you cannot resize it later, nor it will grow automatically.

With dynamic languages it is different, but don't expect handling that much connections with them either.

[ Parent | on HN ]

Re:Tornado: FriendFeed's non-blocking Python web server is n... by riobard on Friday September 11, 2009 @11:09AM (#817466)

It doesn't solve the context _switching_ cost.

[ Parent | on HN ]

Re:Tornado: FriendFeed's non-blocking Python web server is n... by kingkongrevenge on Friday September 11, 2009 @11:42AM (#817528)

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.

[ Parent | on HN ]

Re:Tornado: FriendFeed's non-blocking Python web server is n... by jacquesm on Friday September 11, 2009 @07:53AM (#817175)

You're discounting the output buffer that you will need on a per thread basis (unless you are serving from cache, in which case you can serve the data directly from the cache memory).

Typically an output buffer should be able to hold the complete production for a client, if you limit it to say 4K you will be unable to process a request in one go.

[ Parent | on HN ]