top | item 5446513

10 000 concurrent real-time connections to Django

186 points| mYk | 13 years ago |github.com | reply

39 comments

order
[+] bayesianhorse|13 years ago|reply
I dabbled in realtime connections for a while now, and this is certainly a sexy option to avoid the fragmentation happening in the Python async world.
[+] hoov|13 years ago|reply
Well, I think that was Guido's goal in creating Tulip.
[+] kapilvt|13 years ago|reply
why do people persist in mangling django into doing websocket persitent concurrency when there are better py or otherwise well suited tools to such tasks...
[+] LeafStorm|13 years ago|reply
Because it's a popular, well-written framework with a huge volume of existing code, and integrating WebSockets into Django means you don't have to maintain two codebases if you want to have a realtime Django app.

Also, it's fun.

[+] _fs|13 years ago|reply
What would you recommend as the best tools for accomplishing this?
[+] est|13 years ago|reply
For Python2.X, I think gevent.wsgi.WSGIServer could handle C10k or more, no?
[+] hoov|13 years ago|reply
In my experience -- yes. I've pushed it further than that.

In practice, debugging is an unpleasant experience. If you're doing anything slightly out of the ordinary, you should take care.

[+] fafhrd91|13 years ago|reply
Potentially it is slower than tulip, It does magic stack slicing. also it works only on X86 cpu.
[+] eliben|13 years ago|reply
Very cool, well done.
[+] stefantalpalaru|13 years ago|reply
The C10K problem[1] is about real clients accessing real web servers, not about writing short strings over WebSocket.

I'll associate "C10K" and "Django" when I'll see a dynamic web page being served using the template system, the standard middleware and the ORM (with the default behavior of creating and destroying a database connection for each request).

[1] http://www.kegel.com/c10k.html

[+] mYk|13 years ago|reply
The C10k problem was originally about serving static files -- quoting the page you linked to: "take four kilobytes from the disk and send them to the network".

The demo could certainly be extended to send larger amounts of data -- left as an exercise for the reader.

I'm not sure to understand your second paragraph -- if I used this system in a real application, I would serve the pages with the traditional handler (with template rendering, middleware, etc.) and then exchange messages over the websocket. These are different roles.

Regarding database connections, the default behavior isn't the one you're describing any more; I implemented persistent connections in Django a few weeks ago.

[+] vampirechicken|13 years ago|reply
Why would you insist on creating and destroying a db connection on each request? We stopped doing that decades ago.