#37165: Update Async Topic Docs
-------------------------------------+-------------------------------------
Reporter: Carlton Gibson | Owner: Carlton
Type: | Gibson
Cleanup/optimization | Status: assigned
Component: Documentation | Version: 6.0
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Carlton Gibson:
Old description:
New description:
The main problems are:
1. It strongly implies that Django's asynchronous story is unfinished.
It's **often** liked to in blog posts. And it's totally misleading. The
user API is essentially finished. From the PR: """Many parts of Django
provide asynchronous APIs, including :ref:`the ORM <async-queries>`, the
cache framework, authentication, sessions, mail, and signals. For other
code, the :func:`sync_to_async` adapter is a low-cost bridge (see
:ref:`async_performance`)."""
2. The performance warnings are severely outdated.
`sync_to_async`/`async_to_sync` usage is in the order or microseconds with
modern versions of Python. This plays directly into implementation
considerations where we're constantly pulled towards duplicating whole
code trees, on the mistaken assumption that `sync_to_async` usage (in
particular) incurs a (relatively) massive performance hit.
3. It makes no mention of the remaining async difficulties — such as
concurrent DB queries — which are **not Django specific**. In particular
connection pooling is the appropriate lever to increase throughput,
regardless of whether you're using Django, any other async orm, or raw
connections by hand. (The current phrasing implies it's the ORM that's at
fault here: it's not!)
The topic doc here is a big source of the negative narrative about
Django's async story. It's time to correct that.
--
--
Ticket URL: <
https://code.djangoproject.com/ticket/37165#comment:2>