Djangoは、ASGI の環境下であれば、完璧な非同期リクエストスタックに対応した非同期 ("async") ビューをサポートしています。WSGIの環境下でも非同期ビューは動作しますが、パフォーマンス上不利であるうえ、長期的なリクエストを効率的に処理できません。
\n開発チームはORMや他の機能でも非同期処理が対応できるよう取り組んでいます。この機能は将来リリース予定ですが、現時点では、同期処理と非同期処理のやり取りに、 sync_to_async() アダプターが使えます。さらに同期処理と非同期処理を統合するために、非同期なPythonライブラリがすべて使えます。
どのようなビューでも、呼び出し可能オブジェクトでコルーチンを返すようにすれば、非同期として宣言できます。その際には、一般的に async def を使います。関数ベースのビューの場合、async def を用いてビュー全体を宣言します。クラスベースのビューの場合、get() と post() などのメソッドを async def で宣言します (__init__() でも as_view() でもないことに注意)。
WSGIサーバーでは、非同期ビューは1回限りのイベントループで実行されます。つまり、非同期HTTPリクエストなどの非同期機能を問題なく使用できるものの、非同期スタックのメリットは得られないことになります。
\n非同期スタックの主な利点とは、数百もの接続をPythonのスレッドを使わずに処理できることです。これにより、低速ストリーミング、ロングポーリング、その他の便利なレスポンスタイプが使えます。
\nもしこれらを利用したい場合は、代わりに ASGI を使ってDjangoをデプロイする必要があります。
\n\nASGIとWSGIの両方のモードで、非同期サポートを使用し、シリアルではなく並行してコードを実行することができます。これは特に、外部APIやデータストアを扱う場合に便利です。
\nまだ同期的なDjangoの機能を呼び出したい場合、次のように sync_to_async() でラップする必要があります。
from asgiref.sync import sync_to_async\n\nresults = await sync_to_async(sync_function, thread_sensitive=True)(pk=123)\n非同期ビューから、同期的なDjangoの機能を誤って呼び出そうとすると、Djangoの<async-safety>が発動して、データが破損しないように保護されます。
\n一部の例外を除いて、DjangoはORMクエリーを非同期に実行することもできます。
\nasync for author in Author.objects.filter(name__startswith="A"):\n book = await author.books.afirst()\n詳細については Asynchronous queries で参照できますが、簡単にまとめると次のようになります。
\nSQLクエリを発行するすべての QuerySet メソッドには、a という接頭辞が付いた非同期版があります。
async for は (values() と values_list() を含む) すべてのQuerySetsでサポートされている
Django は、次のような非同期モデルのデータベースを使用するメソッドもいくつかサポートします。
\nasync def make_book(*args, **kwargs):\n book = Book(...)\n await book.asave(using="secondary")\n\n\nasync def make_book_with_tags(tags, *args, **kwargs):\n book = await Book.objects.acreate(...)\n await book.tags.aset(tags)\nトランザクションは非同期モードではまだ機能しません。もしトランザクションの動作が必要なコードがある場合は、そのコードを1つの同期的な関数として書いて、sync_to_async() を使用して呼び出すことをおすすめします。
ビューと異なるモードで実行 (たとえば、非同期のビューを WSGI で実行、従来の同期ビューを ASGI で実行) した場合、Django はコードを実行するために、もう一方の呼び出しスタイルをエミュレートする必要があります。コンテクストスイッチにより、1 ms 程度の小さな性能上のペナルティが与えられてしまいます。
\nこれはミドルウェアでも同様です。Django は同期・非同期の間のコンテクストスイッチの数を最小化するように試みます。もし ASGI サーバーがあっても、すべてのミドルウェアとビューが同期的だった場合、コンテクストスイッチは、サーバーがミドルウェアスタックに入る前の1回だけです。
\nしかし、同期ミドルウェアをASGIサーバーと非同期ビューの間においた場合、サーバーはミドルウェアのために同期モードに切り替え、ビューのために非同期モードにまた戻さなければならなくなります。Django はミドルウェアの例外の伝搬のために同期スレッドも保持し続けます。これは初めは気づかないほどの違いかもしれませんが、1リクエストごとに1スレッドのペナルティが与えられると、非同期の性能上の利点がすべて打ち消されてしまう可能性があります。
\n自分のコード上での ASGI と WSGI の違いの影響を知るためには、自分自身でパフォーマンステストを行うべきです。場合によっては、純粋に同期的なコードベースを ASGI 上で実行した場合でも、性能が向上することがあります。これは、それでもリクエストハンドリングのコードはすべて非同期に実行されるためです。一般的には、ASGI モードを有効にする必要があるのは、プロジェクトに非同期のコードがあるときだけです。
\nDjango の特定の主要なパーツは、コルーチンが感知できないグローバルステートを持つため、非同期の環境では安全に操作できません。これらの Django のパーツは、"async-unsafe" として分類されており、非同期な環境での実行から保護されています。ORM は主な例ですが、この他にもこのように保護されているパーツがあります。
\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.
このエラーが発生した場合は、問題のコードを非同期コンテキストから呼び出さないように修正する必要があります。代わりに、独自の同期関数それ自体の中で async-unsafe と通信するコードを書き、 asgiref.sync.sync_to_async() (または、自スレッド内で同期コードを実行するための他の方法) を使って呼び出します。
非同期コンテキストは、Django コードを実行している環境によって与えられる場合もあります。たとえば、Jupyter notebooks や IPython 対話シェルはともにアクティブなイベントループを透過的に提供してくれるため、非同期 API との対話がより簡単になります。
\nもし IPython shell を使用している場合は、次のコマンドでこのイベントループを無効化できます。
\n%autoawait off\nこれは IPython のプロンプトのコマンドです。これにより同期的なコードを SynchronousOnlyOperation エラーを起こさずに実行できるようになりますが、同時に、非同期 API を await することもできなくなります。イベントループを戻すには、次のコマンドを実行します。
%autoawait on\nIPython 以外の環境にいる場合 (または、何らかの理由で IPython で autoawait がオフにできない場合)、コードが並行して実行される可能性は*確実に*ないため、同期コードは*絶対に*非同期コンテキストから実行する必要があります。このとき、警告は DJANGO_ALLOW_ASYNC_UNSAFE 環境変数を任意の値に設定することで無効化できます。
もし、これをPython内部から行いたい場合は、 os.environ:: を使用してください。
import os\n\nos.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true"\n同期コードを非同期コンテキストから呼び出したり、その逆をするためには、呼び出しスタイルを調整する必要があります。このために、asgiref.sync モジュールの async_to_sync() と sync_to_async() という2つのアダプター関数があります。これらは互換性を維持したまま呼び出しスタイル間を移行するために使われます。
これらのアダプター関数は Django で幅広く利用されています。asgiref パッケージ自体が Django プロジェクトの一部になっており、Django を pip でインストールしたときに自動的に依存関係としてインストールされます。
async_to_sync()Link to this heading#非同期関数を取り、それをラッピングした同期関数を返します。直接ラッパーとしてもデコレーターとしても使用できます。
\nfrom asgiref.sync import async_to_sync\n\n\nasync def get_data():\n ...\n\n\nsync_get_data = async_to_sync(get_data)\n\n\n@async_to_sync\nasync def get_other_data():\n ...\n非同期関数は、もし存在すれば、現在のスレッドのイベントループの中で実行されます。現在のイベントループが存在しない場合、1つの非同期呼び出しのために専用の新しいイベントループが生成され、完了したら再び破棄されます。どちらの状況でも、非同期関数はコードが呼び出されたスレッドとは異なるスレッドで実行されます。
\nthreadlocals および contextvars の値は境界を越えて両方向に保持されます。
\nasync_to_sync() は、本質的に Python 標準ライブラリの asyncio.run() 関数のより強力なバージョンです。threadlocals が確実に動作するようにするだけでなく、it also enables the thread_sensitive mode of sync_to_async() when that wrapper is used below it.
sync_to_async()Link to this heading#同期関数を取り、それをラッピングした非同期関数を返します。直接ラッパーとしてもデコレーターとしても使用できます。
\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\n@sync_to_async\ndef sync_function():\n ...\nthreadlocals および contextvars の値は境界を越えて両方向に保持されます。
\n同期関数はすべてメインスレッド内で実行されることを想定して書かれる傾向があるため、sync_to_async() には2種類の threading モードがあります。
thread_sensitive=True (デフォルト): 同期関数は他のすべての thread_sensitive 関数と同じスレッド内で実行されます。もしメインスレッドが同期的で async_to_sync() ラッパーを使用している場合、このスレッドはメインスレッドになるでしょう。
thread_sensitive=False: 同期関数は、まったく新しいスレッドで実行されます。そのスレッドは、その後呼び出しが完了すると閉じられます。
thread-sensitive モードは極めて特別なモードで、すべての関数が同一スレッドで実行されるようにするためにたくさんの仕事を行います。ただし、メインスレッドで正しく動作するように、*スタック内での * async_to_sync() の使用*に依存していることに注意してください。もし asyncio.run() や類似のメソッドを使用した場合、thread-sensitive な関数は単一の共有スレッドでの実行にフォールバックしますが、これはメインスレッドではありません。
Django でこれが必要な理由は、多くのライブラリ、特にデータベースアダプターが、自分が作られたのと同一スレッド内でのアクセスを必要とするためです。また、既存の多くの Django コードも、すべてが同一スレッドで実行されることを想定しています。たとえば、ビュー内で後で使用するためにリクエストに何かを追加するミドルウェアです。
\nこのコードによって潜在的な互換性の問題を引き起こす代わりに、私たちはこのモードを追加する選択をしました。これにより、既存のすべての Django の同期コードが同一スレッドで実行されるようになり、したがって、非同期モードと完全に互換になります。同期コードは、それを呼び出すすべての非同期コードとは常に*異なる*スレッド内にあるため、生のデータベースハンドルや、その他 thread-sensitive な参照を渡すことは避ける必要があることに注意してください。
\n実用的には、この制限は、sync_to_async() を呼び出すときにデータベースの connection オブジェクトの機能を渡してはならないことを意味します。もしそうした場合、スレッドse-huの安全性チェックがトリガーされます。
# DJANGO_SETTINGS_MODULE=settings.py python -m asyncio\n>>> import asyncio\n>>> from asgiref.sync import sync_to_async\n>>> from django.db import connection\n>>> # In an async context so you cannot use the database directly:\n>>> connection.cursor()\ndjango.core.exceptions.SynchronousOnlyOperation: You cannot call this from\nan async context - use a thread or sync_to_async.\n>>> # Nor can you pass resolved connection attributes across threads:\n>>> await sync_to_async(connection.cursor)()\ndjango.db.utils.DatabaseError: DatabaseWrapper objects created in a thread\ncan only be used in that same thread. The object with alias 'default' was\ncreated in thread id 4371465600 and this is thread id 6131478528.\n代わりに、呼び出しコード内の connection オブジェクトに依存せずに、sync_to_async() で呼び出すことができるヘルパー関数内にすべてのデータベースアクセスをカプセル化する必要があります。