3 ms·

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a huge saving for some projects that call out. Otherwise a lot of stuff has to be done in event queues, to avoid blocking the main thread, and sometimes that means a bad UX when users take actions and aren't offered the guarantee that they are complete - in times where that might be the best option, were you not risking blocking thread.

btown 6y ago
As an FYI: Using a gevent monkey patch has been a way to get async Django for years. Overhead is inefficient in CPU cycles and you need to stay away from doing CPU bound things like Numpy manipulations, but for an app server that’s bound by external API call latency, it practically gives infinite concurrency compared to a thread-per-request model. And no need to worry about event queues. You can feel free to synchronously call requests.get with a 10 sec timeout and still serve prod traffic from a small handful of threads. And most days we don’t even worry about async from a coding perspective. Anyone can email me with questions.
- mgraczyk 6y ago
  I'd add that crucially, DB ORM operations just work with gevent. It will be a while before async database operations are supported natively by Django. For me that is a complete blocker.
  - georgewalker355 6y ago
    > DB ORM operations just work with gevent My impression was that django+gevent requires some care for the db part. The psycopg2 docs state, for instance "Psycopg connections are not green thread safe and can’t be used concurrently by different green threads." [1,2]. In addition, gevent cannot monkey patch psycopg2 code because it is C and not python. This is handled by calling psycopg2.extensions.set_wait_callback() [1,3,4] I just now realize that you're probably referring to making the ORM itself async capable which is on the roadmap https://code.djangoproject.com/wiki/AsyncProject https://code.djangoproject.com/wiki/AsyncProject in which case I totally agree. [1] https://www.psycopg.org/docs/advanced.html#support-for-coroutine-libraries https://www.psycopg.org/docs/advanced.html#support-for-corou... [2] https://stackoverflow.com/questions/12650048/how-can-i-pool-connections-using-psycopg-and-gevent https://stackoverflow.com/questions/12650048/how-can-i-pool-... [3] https://github.com/gevent/gevent/blob/master/examples/psycopg2_pool.py https://github.com/gevent/gevent/blob/master/examples/psycop... [4] https://github.com/psycopg/psycogreen https://github.com/psycopg/psycogreen
    - btown 6y ago
      In practice this is just a one-time setup. We use https://github.com/jneight/django-db-geventpool https://github.com/jneight/django-db-geventpool which uses psycogreen under the hood. It isn't perfect (we're currently tracking down some rare cases where connections aren't properly returning to the pool, though we believe this to be error on our side) but it's more than sufficient. While making the ORM async capable would be great, I'm not sure it will ever make sense to migrate towards sprinkling "async" explicitly across our codebase. We'll see, of course.
- tus88 6y ago
  gevent should be in core.
no_wizard 6y ago
Looks like they will be relying on the ASGI pattern for this? Has anyone had any practice deploying apps with ASGI?
- doteka 6y ago
  Last time I tried deploying Django (with Channels) on ASGI around 2017 or 2018, it was a total clusterfuck and fell over with about 20 websocket connections, and we had to scramble to revert that deployment. That’s not ASGI’s fault though, as there are several reasonably performant frameworks using it.
- sammorrowdrums 6y ago
  Have a production Django site running with Gunicorn / Uvicorn worker and we haven't hit any snags yet. Mind you we're only beginning to use it for anything in particular. The test was to check performance was acceptable, and stable - which has been our experience so far.

btown 6y ago

As an FYI: Using a gevent monkey patch has been a way to get async Django for years. Overhead is inefficient in CPU cycles and you need to stay away from doing CPU bound things like Numpy manipulations, but for an app server that’s bound by external API call latency, it practically gives infinite concurrency compared to a thread-per-request model. And no need to worry about event queues. You can feel free to synchronously call requests.get with a 10 sec timeout and still serve prod traffic from a small handful of threads. And most days we don’t even worry about async from a coding perspective. Anyone can email me with questions.

mgraczyk 6y ago
I'd add that crucially, DB ORM operations just work with gevent. It will be a while before async database operations are supported natively by Django. For me that is a complete blocker.
- georgewalker355 6y ago
  > DB ORM operations just work with gevent My impression was that django+gevent requires some care for the db part. The psycopg2 docs state, for instance "Psycopg connections are not green thread safe and can’t be used concurrently by different green threads." [1,2]. In addition, gevent cannot monkey patch psycopg2 code because it is C and not python. This is handled by calling psycopg2.extensions.set_wait_callback() [1,3,4] I just now realize that you're probably referring to making the ORM itself async capable which is on the roadmap https://code.djangoproject.com/wiki/AsyncProject https://code.djangoproject.com/wiki/AsyncProject in which case I totally agree. [1] https://www.psycopg.org/docs/advanced.html#support-for-coroutine-libraries https://www.psycopg.org/docs/advanced.html#support-for-corou... [2] https://stackoverflow.com/questions/12650048/how-can-i-pool-connections-using-psycopg-and-gevent https://stackoverflow.com/questions/12650048/how-can-i-pool-... [3] https://github.com/gevent/gevent/blob/master/examples/psycopg2_pool.py https://github.com/gevent/gevent/blob/master/examples/psycop... [4] https://github.com/psycopg/psycogreen https://github.com/psycopg/psycogreen
  - btown 6y ago
    In practice this is just a one-time setup. We use https://github.com/jneight/django-db-geventpool https://github.com/jneight/django-db-geventpool which uses psycogreen under the hood. It isn't perfect (we're currently tracking down some rare cases where connections aren't properly returning to the pool, though we believe this to be error on our side) but it's more than sufficient. While making the ORM async capable would be great, I'm not sure it will ever make sense to migrate towards sprinkling "async" explicitly across our codebase. We'll see, of course.
tus88 6y ago
gevent should be in core.

no_wizard 6y ago

Looks like they will be relying on the ASGI pattern for this? Has anyone had any practice deploying apps with ASGI?

doteka 6y ago
Last time I tried deploying Django (with Channels) on ASGI around 2017 or 2018, it was a total clusterfuck and fell over with about 20 websocket connections, and we had to scramble to revert that deployment. That’s not ASGI’s fault though, as there are several reasonably performant frameworks using it.
sammorrowdrums 6y ago
Have a production Django site running with Gunicorn / Uvicorn worker and we haven't hit any snags yet. Mind you we're only beginning to use it for anything in particular. The test was to check performance was acceptable, and stable - which has been our experience so far.