Flask app.run()をスタンドアロンとして使用して複数のクライアントにサービスを提供できますか?


202

FlaskをApacheまたは他のWebサーバーにリンクできることは知っています。しかし、私はFlaskを複数のクライアントに同時にサービスを提供するスタンドアロンサーバーとして実行することを考えていました。

これは可能ですか?複数のスレッドの生成と管理を処理する必要がありますか?

回答:


295

flask.Flask.run**options転送先の追加のキーワード引数()を受け入れますwerkzeug.serving.run_simple-これらの引数の2つはthreaded(ブール値)とprocesses(1より大きい数に設定して、要求を処理するために複数のプロセスを生成するためにwerkzeugを使用できます)。

threadedデフォルトTrueはFlask 1.0以降であるため、Flaskの最新バージョンでは、デフォルトの開発サーバーは複数のクライアントに同時にサービスを提供できます。Flaskの古いバージョンでは、threaded=Trueこの動作を有効にするために明示的に渡すことができます。

たとえば、次のことができます

if __name__ == '__main__':
    app.run(threaded=True)

古いFlaskバージョンと互換性のある方法でスレッドを使用して複数のクライアントを処理する、または

if __name__ == '__main__':
    app.run(threaded=False, processes=3)

着信リクエストを処理する3つのプロセスを生成するようにWerkzeugに指示するか、または単に

if __name__ == '__main__':
    app.run()

Flask 1.0以降を使用することがわかっている場合は、スレッドを使用して複数のクライアントを処理します。

そうは言っても、Werkzeug serving.run_simpleは標準ライブラリのwsgirefパッケージをラップしています。そのパッケージには、実稼働用のWebサーバーではなく、WSGIのリファレンス実装が含まれています。本番環境でFlaskを使用する場合(「本番環境」が同時ユーザー数が10以下の低トラフィックの内部アプリケーションではないと想定)、実際のWebサーバーの背後に立ち上がるようにしてください(Flaskのドキュメントのタイトルのセクションを参照してください)いくつかの推奨される方法の展開オプション)。


2
最大100人のユーザーを表示している場合はどうなりますか?割り当ててprocesses=100、それで満足できますか?私の場合、静的ファイルのみが必要で、HTTP Postメソッドは必要ありません。私の要件は、すべてのFlaskスレッドを親アプリの一部として実行して、変数をすべて共有できるようにすることです。
ATOzTOA 2013

4
Chuckles- @ATOzTOA-いいえ、それはおそらくかなり逆効果になります(プロセスは比較的高価であり、各リクエストで多くの作業を行わない限り、4または8プロセスでは不十分である理由はありません)。とは言っても、静的コンテンツのみを表示している場合は、それを行うために最適化されたサーバー(Apache、ngnix、IIS)を使用したほうがよいでしょう。
Sean Vieira

2
また、通常はリクエスト間で変数を共有する必要はありません。そうする場合は、1つのプロセスに制限するか、帯域外通信(Redis、データベース、ファイルシステムなど)を使用する必要があります。各プロセスの同期が維持されること。
Sean Vieira

3
@ATOzTOA-あなたがより良いサーバーを起動できない場合は、それを試してみて、何が起こるかを確認します。負荷がかかってもうまく機能しない場合は、別のWebサーバーの背後に配置できます。
Sean Vieira

2
@ATOzTOA、「スレッド」と「プロセス」を同時に指定できない理由に関する質問については、次のコードを参照してください:werkzeug.readthedocs.org/en/latest/_modules/werkzeug/serving
pyrho

62

app.run()Flask内からシンプルを使用すると、一度に1つのクライアントのみを処理できる単一のスレッド上に単一の同期サーバーが作成されます。これは、まさにこの理由により、要求の少ない制御された環境(つまり、開発、デバッグ)での使用を目的としています。

スレッドを生成して自分で管理しても、Python GILのため、おそらくそれほど遠くまでは行きません。

とはいえ、まだいくつかの良いオプションがあります。Gunicornは堅固で使いやすいWSGIサーバーであり、複数のワーカー(個別のプロセスであるため、GILは心配しません)を生成でき、非同期ワーカーも付属しているため、アプリの高速化(および安全性の向上)をほとんど必要としません(特にFlaskを使用して)自分の側で何もしないようにします。

それでも、Gunicornでさえ、直接公開されることはおそらくないでしょう。本番環境では、より堅牢なHTTPサーバーの背後で使用する必要があります。nginxはGunicornとFlaskによく合う傾向があります。


17
かなりではありません。GunicornはPythonですが、nginxはそうではありません。しかし、それはあなたがそれらを使用する方法ではありません。Gunicorn gunicorn app:app 127.0.0.1:8080では、の代わりにアプリを実行できますpython app.py。Nginxは、プライベートGunicorn実行アプリ(リバースプロキシ)を公​​開するパブリックサービスとして機能し、あらゆる種類の低レベルのHTTP実装の詳細を隠し、おそらく静的ファイルを直接提供するなど
Ryan Artecona

app.run(threaded = True)を含むFlaskは、Apache2でmod_wsgi フラスコ.palletsprojects.com
en /
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.