Djangoは、 ASGI の環境下であれば、完璧な非同期リクエストスタックに対応した非同期("async")ビューをサポートしています。WSGIの環境下でも非同期ビューは動作しますが、パフォーマンス上不利であるうえ、長期的なリクエストを効率的に処理できません。
\n開発チームはORMや他の機能でも非同期処理が対応できるよう取り組んでいます。この機能は将来リリース予定ですが、現時点では、同期処理と非同期処理のやり取りに、 sync_to_async() アダプターが使えます。さらに同期処理と非同期処理を統合するために、非同期なPythonライブラリがすべて使えます。
Any view can be declared async by making the callable part of it return a\ncoroutine - commonly, this is done using async def. For a function-based\nview, this means declaring the whole view using async def. For a\nclass-based view, this means making its __call__() method an async def\n(not its __init__() or as_view()).
WSGIサーバーでは、非同期ビューは1回限りのイベントループで実行されます。つまり、非同期HTTPリクエストなどの非同期機能を問題なく使用できるものの、非同期スタックのメリットは得られないことになります。
\n非同期スタックの主な利点とは、数百もの接続をPythonのスレッドを使わずに処理できることです。これにより、低速ストリーミング、ロングポーリング、その他の便利なレスポンスタイプが使えます。
\nもしこれらを利用したい場合は、代わりに ASGI を使ってDjangoをデプロイする必要があります。
\n\nASGIとWSGIの両方のモードで、非同期サポートを使用し、シリアルではなく並行してコードを実行することができます。これは特に、外部APIやデータストアを扱う場合に便利です。
\nIf you want to call a part of Django that is still synchronous, like the ORM,\nyou will need to wrap it in a sync_to_async() call. For example:
from asgiref.sync import sync_to_async\n\nresults = await sync_to_async(Blog.objects.get, thread_sensitive=True)(pk=123)\nYou may find it easier to move any ORM code into its own function and call that\nentire function using sync_to_async(). For example:
from asgiref.sync import sync_to_async\n\ndef _get_blog(pk):\n return Blog.objects.select_related('author').get(pk=pk)\n\nget_blog = sync_to_async(_get_blog, thread_sensitive=True)\nIf you accidentally try to call a part of Django that is still synchronous-only\nfrom an async view, you will trigger Django's\nasynchronous safety protection to protect your data from\ncorruption.
\nWhen running in a mode that does not match the view (e.g. an async view under\nWSGI, or a traditional sync view under ASGI), Django must emulate the other\ncall style to allow your code to run. This context-switch causes a small\nperformance penalty of around a millisecond.
\nThis is also true of middleware. Django will attempt to minimize the number of\ncontext-switches between sync and async. If you have an ASGI server, but all\nyour middleware and views are synchronous, it will switch just once, before it\nenters the middleware stack.
\nHowever, if you put synchronous middleware between an ASGI server and an\nasynchronous view, it will have to switch into sync mode for the middleware and\nthen back to async mode for the view. Django will also hold the sync thread\nopen for middleware exception propagation. This may not be noticeable at first,\nbut adding this penalty of one thread per request can remove any async\nperformance advantage.
\nYou should do your own performance testing to see what effect ASGI versus WSGI\nhas on your code. In some cases, there may be a performance increase even for\na purely synchronous codebase under ASGI because the request-handling code is\nstill all running asynchronously. In general you will only want to enable ASGI\nmode if you have asynchronous code in your project.
\nCertain key parts of Django are not able to operate safely in an async\nenvironment, as they have global state that is not coroutine-aware. These parts\nof Django are classified as "async-unsafe", and are protected from execution in\nan async environment. The ORM is the main example, but there are other parts\nthat are also protected in this way.
\nIf you try to run any of these parts from a thread where there is a running\nevent loop, you will get a\nSynchronousOnlyOperation error. Note that you\ndon't have to be inside an async function directly to have this error occur. If\nyou have called a sync function directly from an async function,\nwithout using sync_to_async() or similar, then it can also occur. This is\nbecause your code is still running in a thread with an active event loop, even\nthough it may not be declared as async code.
If you encounter this error, you should fix your code to not call the offending\ncode from an async context. Instead, write your code that talks to async-unsafe\nfunctions in its own, sync function, and call that using\nasgiref.sync.sync_to_async() (or any other way of running sync code in\nits own thread).
The async context can be imposed upon you by the environment in which you are\nrunning your Django code. For example, Jupyter notebooks and IPython\ninteractive shells both transparently provide an active event loop so that it is\neasier to interact with asynchronous APIs.
\nIf you're using an IPython shell, you can disable this event loop by running:
\n%autoawait off\nas a command at the IPython prompt. This will allow you to run synchronous code\nwithout generating SynchronousOnlyOperation\nerrors; however, you also won't be able to await asynchronous APIs. To turn\nthe event loop back on, run:
%autoawait on\nIf you're in an environment other than IPython (or you can't turn off\nautoawait in IPython for some reason), you are certain there is no chance\nof your code being run concurrently, and you absolutely need to run your sync\ncode from an async context, then you can disable the warning by setting the\nDJANGO_ALLOW_ASYNC_UNSAFE environment variable to any value.
もし、これをPython内部から行いたい場合は、 os.environ:: を使用してください。
import os\n\nos.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true"\nIt is necessary to adapt the calling style when calling sync code from an async\ncontext, or vice-versa. For this there are two adapter functions, from the\nasgiref.sync module: async_to_sync() and sync_to_async(). They\nare used to transition between the calling styles while preserving\ncompatibility.
These adapter functions are widely used in Django. The asgiref package\nitself is part of the Django project, and it is automatically installed as a\ndependency when you install Django with pip.
async_to_sync()Link to this heading#Takes an async function and returns a sync function that wraps it. Can be used\nas either a direct wrapper or a decorator:
\nfrom asgiref.sync import async_to_sync\n\nasync def get_data(...):\n ...\n\nsync_get_data = async_to_sync(get_data)\n\n@async_to_sync\nasync def get_other_data(...):\n ...\nThe async function is run in the event loop for the current thread, if one is\npresent. If there is no current event loop, a new event loop is spun up\nspecifically for the single async invocation and shut down again once it\ncompletes. In either situation, the async function will execute on a different\nthread to the calling code.
\nThreadlocals and contextvars values are preserved across the boundary in both\ndirections.
\nasync_to_sync() is essentially a more powerful version of the\nasyncio.run() function in Python's standard library. As well\nas ensuring threadlocals work, it also enables the thread_sensitive mode of\nsync_to_async() when that wrapper is used below it.
sync_to_async()Link to this heading#Takes a sync function and returns an async function that wraps it. Can be used\nas either a direct wrapper or a decorator:
\nfrom asgiref.sync import sync_to_async\n\nasync_function = sync_to_async(sync_function, thread_sensitive=False)\nasync_function = sync_to_async(sensitive_sync_function, thread_sensitive=True)\n\n@sync_to_async\ndef sync_function(...):\n ...\nThreadlocals and contextvars values are preserved across the boundary in both\ndirections.
\nSync functions tend to be written assuming they all run in the main\nthread, so sync_to_async() has two threading modes:
thread_sensitive=True (the default): the sync function will run in the\nsame thread as all other thread_sensitive functions. This will be the\nmain thread, if the main thread is synchronous and you are using the\nasync_to_sync() wrapper.
thread_sensitive=False: the sync function will run in a brand new thread\nwhich is then closed once the invocation completes.
Thread-sensitive mode is quite special, and does a lot of work to run all\nfunctions in the same thread. Note, though, that it relies on usage of\nasync_to_sync() above it in the stack to correctly run things on the\nmain thread. If you use asyncio.run() or similar, it will fall back to\nrunning thread-sensitive functions in a single, shared thread, but this will\nnot be the main thread.
The reason this is needed in Django is that many libraries, specifically\ndatabase adapters, require that they are accessed in the same thread that they\nwere created in. Also a lot of existing Django code assumes it all runs in the\nsame thread, e.g. middleware adding things to a request for later use in views.
\nRather than introduce potential compatibility issues with this code, we instead\nopted to add this mode so that all existing Django sync code runs in the same\nthread and thus is fully compatible with async mode. Note that sync code will\nalways be in a different thread to any async code that is calling it, so you\nshould avoid passing raw database handles or other thread-sensitive references\naround.
\n