Apacheインスタンスのロードテスト中に504ゲートウェイタイムアウトが発生します。

Apacheインスタンスのロードテスト中に504ゲートウェイタイムアウトが発生します。

Apacheインスタンスを介してデプロイされたLaravelアプリケーションがあります。インスタンス構成は次のとおりです。

T3A.2xLarge  (vCPU = 4, Memory 16 GIB)

Apacheタイムアウトを600秒に増やし、mpm_prefork次のように設定しました。

    <IfModule mpm_prefork_module>
            StartServers            16
            MinSpareServers         0
            MaxSpareServers         0
            MaxClients              16
            ServerLimit             256
            MaxRequestWorkers       400
            MaxConnectionsPerChild  25
    </IfModule>

それに応じてPHP設定も変更しました。

RDS DBのmax_connectionは600なので、maxRequestWorkerを400から600に設定しないとエラーが発生しますToo Many Connection

ただし、この構成では、20回のランプアップサイクルごとに3000人のユーザーをロードテストすると、504 Gateway Timeout要求の半分にエラーが発生します。

しかし、他のツールとエラーログを見てもエラーは記録されません。

構成に関する提案はありますか?

答え1

この特定のバグを見つけることが負荷テストを実行する理由の90%です。

AWSでこれを行っているので、Application Load Balancerを使用しているとします。 504通常、アプリケーションが十分に速く応答せず、ロードバランサーが放棄した結果です。

この問題の原因を説明するログを取得する可能性はほとんどありません。アプリケーションサーバーはすべてが大丈夫だと思い、ロードバランサーは待機を放棄した可能性が高いです。

私は信じる接続アイドルタイムアウトロードバランサのタイムアウトに影響します。デフォルトは60です(サーバーに設定した600よりはるかに高い)。しかし、ユーザーを長く待つことは非常に悪い経験であることに注意してください。

それ以外の場合は、なぜサーバーがそんなに遅く実行されているのかを調べる必要があります。サーバーの応答速度を低下させるボトルネックを見つける必要があります。複数の可能性があります。これは次のようになります。

  • システムリソース不足:CPUおよび/またはメモリ
  • ディスクIO - 特にGP2 EBSを使用する場合 - 代わりにGP3を使用する
  • 遅いRDS応答などのダウンストリームの問題 - RDSなどでリソースの問題を見つけます。
  • ロックの問題。たとえば、アプリケーションがデータベースを更新すると、すべてのクライアントが競合する可能性があります。この場合、アプリケーションを修復する必要があるかもしれません。

関連情報