21–30 of 36 posts
Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497
This implementation is probably a little different but we were using long poll in the late 90s and early 2000s. The problem was that you were committing one thread (or worse, one process) to each client. That obviously doesn't scale unless threads are extremely light on RAM and either the OS or the runtime support a large number of them. I remember that a way out was using continuations. Jetty was a Java application…
This is mostly true today as well, although we do have beefier machines and more efficient thread pooling.
I did some personal research for infrequent real-time notifications. My conclusion was that many stateful connections are poorly memory-optimized by language runtimes and reverse proxies. Even with lightweight tech like Golang, gRPC, nginx, etc, it’s hard to push anything less than 30 kB for an idle conn, mostly from thread/goroutine stacks, user space buffers and (easy to overlook) a bunch of HTTP headers and TLS handshake state that often remain after establishing the conn. That’s without any middleware or business logic wants their share of the cake.
The only mature project I found that really took this stuff seriously is uWebSockets. It’s extremely lightweight, around an OOM better than most alternatives. Highly recommend – they also have a socket library so you can implement other protocols if needed.
Anyway, it’s important to be aware that massive amounts of long running connections is not just about adding a websocket/SSE library. Chances are you’ll need a mostly-separate serving stack for that purpose.
Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497
I'll have zero trust running async Django until all sync_to_async and async_to_sync calls are removed from the code base.
I have 7 YoE with Django. Its great at so many things. You see some code, like middlewares, and immediately understand what's going on.
Now, we also have Starlette. The base of all new, fancy asgi libraries. Here's the base middleware class.
https://github.com/encode/starlette/blob/8d7a1cacfb3e1a30cbb...
In the last couple of years I heard 'we're running fastapi on production. Wanna join us?' so many times... but the reality is that it's still not suitable for prod. Who wants to work with a code like that if you have a readable, stable Django? I'm clueless.
Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497
Running Postgres without a connection bouncer is a huuuge no-no already, but if this breaks the default mode of pgbouncer it’s basically a showstopper.
Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497
Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497
All the new asyncIO stuff in Django is awesome, they are doing a phenomenal job retrofitting it all to an inherently sync designed framework. One thing to note, it's been possible to build these sort of things with Django by using Gevent and Gunicorn for over a decade, and it works well. In many ways I wish Gevent had been adopted by Python rather than AsyncIO.
All the new asyncIO stuff in Django is awesome, they are doing a phenomenal job retrofitting it all to an inherently sync designed framework. One thing to note, it's been possible to build these sort of things with Django by using Gevent and Gunicorn for over a decade, and it works well. In many ways I wish Gevent had been adopted by Python rather than AsyncIO.
Hi, thank you for your comment. I have been looking for correct ways to integrate websockets on my django app. Currently I'm using gevent gunicorn setup. Can you elaborate a bit more on how to make websockets work with an existing app? Thanks.
All the new asyncIO stuff in Django is awesome, they are doing a phenomenal job retrofitting it all to an inherently sync designed framework. One thing to note, it's been possible to build these sort of things with Django by using Gevent and Gunicorn for over a decade, and it works well. In many ways I wish Gevent had been adopted by Python rather than AsyncIO.
Where can I learn more about this? I've been thinking of trying to integrate Supabase Realtime ( https://github.com/supabase/realtime ) into my Django app (without the rest of Supabase), but I'd also like to keep things even simpler if possible. Also, what was the reason not to go with Gevent?
Do modern chat actually use websocket and the like? Discord / Slack on the web ( browser ) what do they use?