10 000 concurrent real-time connections to Django
1–10 of 40 posts
Re: 10 000 concurrent real-time connections to Django
#2why do people persist in mangling django into doing websocket persitent concurrency when there are better py or otherwise well suited tools to such tasks...
Re: 10 000 concurrent real-time connections to Django
#3why do people persist in mangling django into doing websocket persitent concurrency when there are better py or otherwise well suited tools to such tasks...
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.
Re: 10 000 concurrent real-time connections to Django
#4The 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).
Re: 10 000 concurrent real-time connections to Django
#5why do people persist in mangling django into doing websocket persitent concurrency when there are better py or otherwise well suited tools to such tasks...
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.
how much of that existing code has any application in a websocket context.. if it uses the orm layer throw it out.. if it uses the template layer.. optionally throw it out for efficiency (jinja and friends).. what are you really left with... routing.. trivial.. a familiar api with the guts out.. overrated and a hobgoblin of consistency.
Re: 10 000 concurrent real-time connections to Django
#6why do people persist in mangling django into doing websocket persitent concurrency when there are better py or otherwise well suited tools to such tasks...
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.
Indeed, these are the exact reasons!
Re: 10 000 concurrent real-time connections to Django
#7The 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
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.
Re: 10 000 concurrent real-time connections to Django
#8Very cool, well done.
Re: 10 000 concurrent real-time connections to Django
#9Earlier quoted context omitted.
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.
how much of that existing code has any application in a websocket context.. if it uses the orm layer throw it out.. if it uses the template layer.. optionally throw it out for efficiency (jinja and friends).. what are you really left with... routing.. trivial.. a familiar api with the guts out.. overrated and a hobgoblin of consistency.
This system doesn't replace Django; it complements it.
You could build 95% of an application with the traditional request-response model and add the 5% of real-time featurs with a system similar to my demo.
(Of course, given your opinions on Django, I don't recommend you build anything with it.)
Re: 10 000 concurrent real-time connections to Django
#10The 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
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 (wi…
Static files are no longer a problem thanks to Varnish or nginx. And this is Django, after all, so please focus on dynamic content performance.
I'm glad to hear that Django managed to get persistent db connections after years of "just use PgPool/PgBouncer". Keep up the good work!