1つのFlaskプロセスが同時にいくつのリクエストを受け取るのですか?


138

私はFlaskを使用してアプリを構築していますが、WSGIについてはあまり知りませんが、それはHTTPベースのWerkzeugです。Gunicornと4つのワーカープロセスでFlaskアプリケーションのサービスを開始すると、4つの同時リクエストを処理できることになりますか?

私は同時リクエストを意味し、1秒あたりのリクエストやその他のものではありません。

回答:


183

開発サーバーを実行している場合-これを実行app.run()すると、単一の同期プロセスが取得されます。つまり、一度に最大で1つのリクエストが処理されます。

デフォルトの構成でGunicornをその前に固定し、の数を増やすだけで--workers、基本的には、それぞれがapp.run()開発サーバーのように動作する(Gunicornによって管理される)プロセスの数が得られます。4ワーカー== 4同時リクエスト。これは、Gunicornがsyncデフォルトで含まれるワーカータイプを使用するためです。

Gunicornも、すなわち、非同期の労働者が含まれていることに注意することが重要であるeventletgevent(ともtornado、それはトルネードフレームワークで使用するのが最善です、それはそう)。これらの非同期ワーカーの1つを--worker-classフラグで指定すると、Gunicornが多数の非同期プロセス管理し、それぞれが独自の同時実行性管理します。これらのプロセスはスレッドを使用せず、代わりにコルーチンを使用します。基本的に、各プロセス内で同時に発生できるのは1つだけ(1スレッド)ですが、オブジェクトが外部プロセスの終了を待機している場合(データベースクエリやネットワークI / Oを待機している場合など)、オブジェクトは「一時停止」できます。

つまり、Gunicornの非同期ワーカーの1つを使用している場合、各ワーカーは一度に複数のリクエストを処理できます。最適なワーカーの数は、アプリの性質、環境、アプリが実行されるハードウェアなどによって異なります。詳細については、Gunicornのデザインページと、イントロページでのgeventの動作に関するメモをご覧ください。


4
Gunicornはバージョン19以降、「実際の」スレッドをサポートするようになりましたこちらこちらをご覧ください。
Filipe Correia

2
どのリソースが(どのように)共有され、どれがスレッド/プロセス間で完全に分離されているかをどのように追跡するのですか?たとえば、Gunicornによって処理され、Flaskハンドラーで使用されるいくつかのプロセス間で巨大なデータ構造を共有したい場合はどうすればよいですか?
Johann Petrak

@Johsmに尋ねるのは、オペレーティングシステム内の異なるプロセス間でデータを共有する方法を尋ねるようなものです。それに対する答えはあなたの質問に答えることができます、プロセスは他のプロセスとメモリを共有しないため、外部ストレージを使用する必要があります。GunicornはマルチプロセッシングCPUアーキテクチャを利用するためだけに存在し、それらの問題を処理しません。
adkl

イブはどうですか?これはイブにも当てはまりますか?
Eswar、

2
v1.0の(以降、デフォルトでフラスコの開発サーバーが使用するスレッドgithub.com/pallets/flask/pull/2529
hychou

40

現在、すでに提供されているソリューションよりもはるかに簡単なソリューションがあります。アプリケーションを実行するときは、次のようにthreaded=Trueパラメーターをapp.run()呼び出しに渡すだけです。

app.run(host="your.host", port=4321, threaded=True)

werkzeug docsで確認できる別のオプションは、processesパラメーターを使用することです。このパラメーターは、処理する並行プロセスの最大数を示す1 より大きい数値を受け取ります。

  • スレッド化–プロセスは各要求を個別のスレッドで処理する必要がありますか?
  • プロセス– 1より大きい場合、この最大数の同時プロセスまで、新しいプロセスの各要求を処理します。

何かのようなもの:

app.run(host="your.host", port=4321, processes=3) #up to 3 processes

ここでのrun()メソッドの詳細と、ソリューションとAPIリファレンスを見つけるためのブログ投稿


注:上のフラスコドキュメントにrun()方法、(ので、プロダクション環境でそれを使用することが推奨されていることを示しています引用は:)それはうまくスケールしないよう、「軽量で使いやすい一方で、フラスコに内蔵されているサーバーは、生産には適していません」

ただし、本番環境への移行時にこれを行うための推奨方法については、導入オプションページを参照しています。


5
情報をありがとう。実行用のドキュメントには、セキュリティまたはパフォーマンスの要件を満たしていないことを記載して、本番環境では使用しないように記載されていることに注意することが重要です。
Coffee_fan

1
@Coffee_fanあなたは正しいです。最新の1.1.xでさえ、彼らはそれを思いとどまらせ、代わりに、本番に行くときはデプロイメントオプションのページを確認することを勧めます。貴重な観察結果を回答に含める:)
DarkCygnus

33

Flaskは、スレッドごとに同時に1つのリクエストを処理します。それぞれ4つのスレッドを持つ2つのプロセスがある場合、それは8つの同時要求です。

Flaskはスレッドやプロセスを生成または管理しません。それがWSGIゲートウェイ(たとえば、gunicorn)の責任です。


9

いいえ、あなたは間違いなくそれ以上のものを扱うことができます。

シングルコアマシンを実行している場合、CPUは実際には一度に1つの命令のみを実行することを前提としています。

つまり、CPUは非常に限られた命令セットしか実行できず、クロックティックごとに複数の命令を実行できません(多くの命令は1ティックを超える場合もあります)。

したがって、コンピュータサイエンスで私たちが話している同時実行性のほとんどはソフトウェアの同時実行性です。言い換えると、最下位レベルのCPUを抽象化し、コードを同時に実行していると思わせるソフトウェア実装のレイヤーがあります。

これらの「もの」はプロセスとすることができます。これは、各プロセスが独自の非共有メモリを使用して独自の世界で実行していると考えるという意味で同時に実行されるコードの単位です。

もう1つの例はスレッドです。これは、同時実行を可能にするプロセス内のコードの単位でもあります。

4つのワーカープロセスが4つを超えるリクエストを処理できるようになるのは、それらがより多くのリクエストを処理するためにスレッドを起動するためです。

実際のリクエスト制限は、選択したHTTPサーバー、I / O、OS、ハードウェア、ネットワーク接続などによって異なります。

幸運を!

*命令は、CPUが実行できる非常に基本的なコマンドです。例-2つの数値を追加し、1つの命令から別の命令にジャンプする


1
それはgunicornがスレッドまたはFlaskを生み出しているのですか?どちらかの可能性を裏付ける証拠は見つかりませんでした。
jd。

1
もちろん、プロセスについては理解していますが、答えは、必要に応じてより多くのスレッドが生成されることを示しています。それを確認したいのですが。
jd。

4
「深く掘り下げて、シングルコアマシンを実行している場合、CPUは実際には一度に1つの命令のみを実行しますこれは最近のマシンでは正しくありません。最新のCPUのほとんどはパイプライン化されており、スーパースカラーです。単一のコアでも複数の実行ユニットと、ソフトウェア側から見た「マシンコード」を個々の実行ユニットにディスパッチされる実際のハードウェアマイクロopに変換する命令デコーダーがあります。
Michael Geary

1
明確にするために、当時のCPUは、実際には実行可能ファイル(マシンコード)で数値命令を直接実行していました。すべてのCPUリファレンスには、メモリリファレンスを含め、各命令に要したクロックサイクル数を示す命令タイミングチャートがありました。そのため、タイミングを合計して、コードの一部にかかる時間を知ることができます。最近のCPUはそのようなものではありません。興味深い例外の1つは、BeagleBoneです。このBeagleBoneには、最新のスーパースカラーARMプロセッサと、命令タイミングが固定された2つの旧式の「PRU」プロセッサがあります。
Michael Geary

1
それを明確にするため、私が「モダン」と言ったとき、それをARM / Intel / AMDチップ(パイプライン、スーパースカラーなど)のようなプロセッサの緩い省略形として使用していました。もちろん、固定タイミングで古い方法で動作する最新のプロセッサもあります。命令ごとに、前述のBeagleBone PRUやさまざまな新しいマイクロコントローラーのように。(そして今度はGunicornに戻ります!)
Michael Geary
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.