サーバーで重複した HTTP リクエストを受信した場合、どのように対処すればよいでしょうか?
サーバー上でビルドしてクライアントに戻るまでに約 30 秒かかる LAMP Web アプリに関するレポートがあります。クライアントは焦り、最初のレポートが完了する前にレポートを再実行します。これにより、サーバーが停止します。このサーバー側を処理/防止する方法はありますか?
サーバーで重複した HTTP リクエストを受信した場合、どのように対処すればよいでしょうか?
サーバー上でビルドしてクライアントに戻るまでに約 30 秒かかる LAMP Web アプリに関するレポートがあります。クライアントは焦り、最初のレポートが完了する前にレポートを再実行します。これにより、サーバーが停止します。このサーバー側を処理/防止する方法はありますか?
ジョブがすでにどこかで実行されているという事実を保存します。
レポートを生成するコードで、レポートが既に実行されているかどうかを確認します。もしそうなら、別のものを実行しないでください。
レポートの生成が終了するか、例外的な条件を処理するためにタイムアウトが発生したら、その事実を保存解除します。
データベース、memcached サーバー、redis、テキスト ファイル、共有メモリへの書き込みなどを使用できます。
現在、何かが処理されていることをユーザーに伝えるには、AJAX を使用する傾向があります。
通常、リクエストをサーバーに送信すると、サーバーは 202 レスポンスと、ブラウザーが結果を見つけるためのアドレス (おそらく UUID を含む) を返します (必ずしも直接表示する必要はありませんが、バックグラウンドで保持します)。 JavaScript をサポートしていないクライアントの場合は、これを直接表示することもできます)。
次に、そのアドレスに対してバックグラウンドで後続のリクエストを行い、準備ができたら結果を表示します。
このアプローチには、よりユーザーフレンドリーであるという利点があるだけでなく、切断に対してより堅牢でもあります。
サーバー上で構築しているものが完了するまで 202 応答を返してから、キャッシュされたコピーを提供することができます。
30 秒は、今日の Web アプリの世界でユーザーを待たせるには長すぎます。Google はその 100 分の 1 の時間でウェブ全体を検索します。Web アプリをより高度なものにしたり、データを消費したりするものは何ですか。最適化後も 1 つのインスタンスで処理できない場合は、クラウド (または複数のサーバー) にスケールアウトすることをお勧めします。本当に要求が厳しい場合は、複数のインスタンスから並行して実行できるサブタスクに分割します。
あなたが尋ねなかった質問への回答ではなく、あなたの直接の質問について。上記の答えにはいくつかのトリックがあります。頻繁に要求されるクエリを、それらが来る前に生成するか、レンダリングに対して最初の要求のみを行い、その要求が完了するのを待ってから結果を送信することができます。