これらのリクエストは、アプリケーションですぐに処理されることになっています。ミリ秒未満にすることで、これによりアプリケーションが解放されてさらに多くのリクエストを受けられるようになり、訪問者に対して高品質のユーザーエクスペリエンスを提供できます。リクエストが異常停止したり、アプリケーションによる処理に非常に時間がかかったりすることがあります。秒を超えると、ルーターはリクエストを強制終了します。送信されてから開始されます。秒以内にルーターに返信される必要があります。エラー​がアプリケーションログに送出されます。ルーターはクライアントに応答を返す一方、アプリケーションは処理中のリクエストがタイムアウトになったことを認識しないため、アプリケーションはリクエストの処理を続行します。設定することをお勧めします。ルーティングのタイムアウトとは異なり、これらのタイマーは、アプリケーションによるリクエストの処理が開始されたときに始まります。これについて詳しくは、以下の「タイムアウトの動作​」を参照してください。タイムアウト値は設定できません。送信するようにすることをお勧めします。プロセスが解放されてさらに多くの作業が実行できるようになり、アプリケーションの全体的な応答時間が減少します。機能をサポートします。秒の初期ウィンドウがあります。秒間のローリングウィンドウに再設定されます。秒間のウィンドウ期間中にデータが送信されない場合、接続は強制終了されます。サーバー送信イベント​などのストリーミング応答を送信している場合、クライアントがハングアップしたときに検出する必要があり、アプリサーバーが接続をすぐにクローズするようにしてください。秒間オープンしたままにした場合、リクエストタイムアウトが発生します。接続が強制終了されると、クライアントに対してエラーページが発行されます。そのまま放置され、応答を送信できなくてもリクエストの処理を続行します。応答できないため、さらなる悪化を引き起こします。言語によっては、アプリサーバーレベルでタイムアウトを設定できる場合もあります。次のようにタイムアウトを設定できます。送信しますが、例外は生成されません。サーバーレベルのタイムアウトの他に、別のリクエストタイムアウトライブラリを使用できます。秒などに設定することです。いつまでも残ることを防ぎますが、時間のかかるリクエストのソースの追跡がかなり容易になるエラーを生成します。類似のツールは他の言語でも存在し、あるいはランタイムに組み込まれています。リクエストタイムアウトのデバッグリクエストタイムアウトの一因は、コード内の無限ループです。(多くの場合は本番データベースのローカルコピーを使用します。問題を再現してバグを修正できるか確認します。プロセス内部で実行しようとしていることがあります。リクエストとは非同期的に実行できるバックグラウンドジョブに移動する必要があります。dyno、バックグラウンドジョブおよびキューイング​」を参照してください。アプリケーションによって使用されている外部サービスが利用できないか過負荷状態になったときに、別の種類のタイムアウトが発生します。アプリは高い確率でタイムアウトします。リクエスト中に処理しなければならない場合は、エラーの発生に備えて常に計画しておく必要があります。リクエストに関するタイムアウトを指定できます。ワーカーを強制終了する可能性があります。詳細は、ナレッジベースの記事​を参照してください。接続のキューイングが原因で発生することもあります。同時に送信することができます。この場合、リクエストはアプリによって処理中のリクエストの後ろにキューイングされ、これらの後続のリクエストは独自に処理されるよりも長い時間がかかることになります。使用していくらか可視化できます。(一般的に効果の高い順に記載されています)。ツールを試してみてください。個々のキューを多くのプロセスで共有することによって、リクエストキューイングの効率が大幅に改善されます。アプリのコードを最適化することで時間のかかるリクエストの速度を上げます​。パーセンタイルとアプリの最大サービス時間に注目します。これにより、リクエストが時間のかかる別のリクエストの後ろで待機する時間が減少します。増やすことで​、全体の並列性を増やします。これにより、特定のリクエストが別のリクエストの背後で詰まって処理されなくなる可能性がわずかに低下します。アプリケーションではユーザーがファイルをアップロードできます。秒を超えることがあります。リクエストタイムアウトが発生することがあります。直接アップロードする​ことをお勧めします。Preferences。