Web サーバーは、同時に多くの要求を処理する必要がある場合があります。Pythonインタープリターには実際にGIL制約があるため、同時実行はどのように実装されていますか?
複数のプロセスを使用し、IPC を使用して状態を共有していますか?
Web サーバーは、同時に多くの要求を処理する必要がある場合があります。Pythonインタープリターには実際にGIL制約があるため、同時実行はどのように実装されていますか?
複数のプロセスを使用し、IPC を使用して状態を共有していますか?
通常、多くのワーカー (つまり、gunicorn) があり、それぞれが独立したリクエストで派遣されます。他のすべて(同時実行関連)はデータベースによって処理されるため、抽象化されます。
IPC は必要ありません。必要なのは、RDBMS、キャッシュ サーバー (redis、memcached) などの「単一の信頼できる情報源」だけです。
まず、リクエストは独立して処理できます。ただし、サーバーは、一度に処理できるリクエストの数を最大に保つために、それらを同時に処理したいと考えています。
この並行性の概念の実装は、Web サーバーによって異なります。
一部の実装では、リクエストを処理するためのスレッドまたはプロセスの数が固定されている場合があります。すべてが使用中の場合、追加のリクエストは処理されるまで待機する必要があります。
別の可能性として、リクエストごとにプロセスまたはスレッドが生成されることがあります。リクエストごとにプロセスを生成すると、途方もないメモリと CPU のオーバーヘッドが発生します。軽量スレッドを生成する方が優れています。そうすることで、毎秒数百のクライアントにサービスを提供できます。ただし、スレッドも管理オーバーヘッドをもたらし、メモリと CPU の消費量が高くなります。
毎秒数千のクライアントにサービスを提供する場合、非同期コルーチンに基づくイベント駆動型アーキテクチャは最先端のソリューションです。これにより、サーバーは無数のスレッドを生成することなく、高速でクライアントにサービスを提供できます。いわゆる C10k 問題のウィキペディアのページに、 Web サーバーのリストがあります。それらの中で、多くはこのアーキテクチャを利用しています。
コルーチンは Python でも利用できます。http://www.gevent.org/をご覧ください。そのため、たとえばuWSGI + geventに基づく Python WSGI アプリは非常にパフォーマンスの高いソリューションです。
普段通り。Web サービスはほとんど I/O バウンドであり、GIL は I/O 操作中に解放されます。そのため、特別な調整なしでスレッド化が使用されるか、イベント ループ (Twisted など) が使用されます。