WSGIの代わりにASGIを使用することの短所
HTTPリクエスト処理 Django一般に、WSGIの代わりにASGIを使用することの明示的で明確な欠点は何ですか？
ASGIが非同期タスク用であることは知っていますが、http.*チャネルを介して同期HTTPリクエストを処理することもできます。通常のWSGIよりも遅いですか、またはWSGIと比較してサポートされていない機能はありますか？
もう1つは、同じプロジェクトでREST APIとWebSocketの両方の処理を提供するために、どちらの方法が望ましいのか、またその理由は何ですか。
- WSGI for REST + ASGI for websocket for different server instances
- WSGI for REST + ASGI for websocket in same machine
- 両方のASGI
私はベンチマークを行いませんでしたが、いくつかのプロジェクトでWSGIとASGIの両方を使用し、それらのパフォーマンスの間に十分な違いが見られなかったため、Django WSGIパフォーマンスが許容できる場合、ASGIはあまりにも動作します。
REST + websockets APIの場合、両方にASGIを使用しました。プロジェクトでASGIを有効にしている場合（WSGIはASGIで動作します）、WSGIを使用する理由はありません。
ASGIサーバーの方が新しいため、テストが少なく、機能が少なく、数が少なく、背後に小さなコミュニティーがある可能性があります。ただし、私はすべてにASGIサーバー（Daphne）を使用しており、WebSocketはユーザーエクスペリエンスの面で非常に多くのことを提供しているため、すべてが最終的にASGIに移行すると感じています。
コードでasyncioを使用できることは、Webプログラミングの主な利点です。 10個のクエリを次々に実行して、それぞれが返ってくるのを待つ代わりに、キャッシュをヒットして単一のスレッドで同時にHTTPリクエストを作成しながら、同時に10個のクエリを実行できます。