FastAPI (または Flask) アプリが高負荷でパフォーマンスが低下する理由

まず第一に、タイトルの餌で申し訳ありませんが、昨夜この問題を理解しましたが、まだドーパミンラッシュの影響下にあります。これを共有する必要があります。

このテキストは、初心者レベルの開発者またはデータ サイエンティスト (上級 Python ソフトウェア エンジニアではない) を対象としており、「技術論文」ではなく、物語、つまり、起こった出来事の時系列の流れとしてこれを書きます。 (問題、解決策、ディスカッションで構成されています) 私はこのアプローチが気に入っています。なぜなら、物事が現実にどのように起こるかを示すからです。

初期の考慮事項

これらのテストは、単一プロセッサと 512M RAM マシンを使用して GCP Cloud Run で実行され、素晴らしいツール (Python、LoL 用) Locust を使用しました。

また、Postman の単一リクエストでパフォーマンスの問題がすでに発生している場合は、FastAPI のパフォーマンス向上に特化した Kisspeter のこのリポジトリと LoadForge のこのリポジトリを参照することを強くお勧めします。

最初のテストラウンド

Cloud Run の開始後、Postman で 1 つのリクエストを使用すると、応答時間は約 400 ミリ秒でした。最高ではありませんが、完全に許容範囲内です。

私たちの負荷テストは非常に単純です: 1 つのテーブルで読み取り、書き込み、削除 (または API エンドポイントへの GET、POST、DELETE) を行います。 75% が読み取り、20% が書き込み、5% が削除。 100 人の同時ユーザーで 10 分間実行します。

最終的に平均応答時間は 2 秒になりましたが、最も気になるのは、テストが終了した時点でも平均時間がまだ増加していたということです。そのため、安定する前に (そして安定した場合には) この数値はさらに増加する可能性が非常に高いです。 .

自分のマシンでローカルに実行しようとしましたが、驚いたことに、Postman の応答時間はわずか 14 ミリ秒でした。しかし、500 人の同時ユーザーに対して負荷テストを実行すると、問題が再び発生しました。 ...

テストの終わりまでに、応答時間は約 1.6 秒で、まだ増加していましたが、何らかの不具合が発生し、95 パーセンタイルが急上昇しました (そして、グラフ =( ) が台無しになりました。統計は次のとおりです:

では、なぜ 14 ミリ秒で応答するサーバーが、同時ユーザー数が 500 人だけの場合に突然 1.6 秒に達するのでしょうか?

私のマシンは core i7、6 コア、2.6 GHz、16 GB RAM、SSD です。そんなことはあってはならないことです。

良いヒントを与えてくれたのは、プロセッサとメモリのログでした...それらは非常に低かったです!

これはおそらく、サーバーがマシンのリソースをすべて使用していないことを意味します。そして、何だと思いますか？そうではありませんでした。 FastAPI または Flask アプリケーションを prod (プロセス ワーカー) にデプロイするときに、大多数の開発者が忘れている概念を紹介しましょう。

getorchestra.io によると:

サーバーワーカーについて理解する

サーバー ワーカーは本質的に、アプリケーション コードを実行するプロセスです。各ワーカーは一度に 1 つのリクエストを処理できます。複数のワーカーがある場合は、複数のリクエストを同時に処理でき、アプリケーションのスループットが向上します。

サーバーワーカーが重要な理由

• 同時実行性: リクエストの同時処理が可能になり、サーバー リソースの利用効率が向上し、応答時間が短縮されます。
• 分離: 各ワーカーは独立したプロセスです。 1 つのワーカーに障害が発生しても、他のワーカーには影響しないため、安定性が向上します。
• スケーラビリティ: ワーカーの数を調整することで、アプリケーションを簡単に拡張してさまざまな負荷に対応できます。

実際には、オプションの --workers パラメータをサーバーの初期化行に追加するだけです。必要なワーカーの数の計算は、アプリケーションを実行しているサーバーとアプリケーションの動作、特にメモリ消費量に大きく依存します。

これを実行した後、16 ワーカーに対してローカルではるかに良い結果が得られ、10 分後には 90 ミリ秒 (同時ユーザー 500 人の場合) に収束しました。

最終テストラウンド

適切なワーカー数でマイクロサービスを構成した後（単一プロセッサの Cloud Run インスタンスには 4 つを使用しました）、GCP での結果は信じられないほど良くなりました。

GCP サーバーでのテストの終了時に最終値は 300 ミリ秒に収束しますが、これは少なくとも許容範囲内です。 ?

以上がFastAPI (または Flask) アプリが高負荷でパフォーマンスが低下する理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。