非常に長いタスクを実行するオフサイト サーバーへのインターフェイスとして機能する Web アプリケーションがあります。ユーザーが情報を入力して送信すると、chrome は応答を待ち、応答を受信すると新しい Web ページを読み込みます。ただし、ネットワークやユーザーの入力によっては、タスクにかなりの時間がかかる場合があり、データが返される前に chrome が「データを受信していないページ」をロードすることがあります (ただし、タスクはまだ実行中です)。
私のタスクが考えている間に一時的なページを置くか、単にクロムを強制的に待機させる方法はありますか? 前もって感謝します
サーバーのタイムアウトやその他のトリックを変更してページを「有効」に保つことができますが、制御できない接続の他の部分があり、リクエストがタイムアウトになる可能性があることに注意してください (タイムアウトなど)。ブラウザの値、またはブラウザとサーバー間のプロキシなど）。また、タスクの完了に時間がかかる場合 (より高度になったり、より多くの人がタスクを使用するために遅くなったりする場合) は、タイムアウト値を常に上げておく必要があるかもしれません。
最終的に、この種の問題は通常、アーキテクチャを変更することで解決されます。
リクエストを送信して処理ビューでタスクを実行するのではなく、ビューは別のプロセスでタスクの実行を開始し、すぐに応答を返します。この応答により、ユーザーは「お待ちください。処理中です」というページに移動できます。そのページでは、多くのプッシュ テクノロジの 1 つを使用して、タスクがいつ完了したかを判断できます (ロング ポーリング、Web ソケット、サーバー送信イベント、N 秒ごとの AJAX 要求、または非常に単純な方法: ページをリロードする)。 5秒ごと）。
とにかく、先ほど言ったように、リクエストを処理するビューは長いアクションを実行しません。バックグラウンド プロセスを開始してタスクを実行するだけです。このバックグラウンド プロセス ディスパッチを自分で作成するか (考えられるアイデアについては、この Flask スニペットを参照してください)、 Celeryや ( RQ ) などのライブラリを使用できます。
タスクが完了したら、何らかの方法でユーザーに通知する必要があります。これは、上で選択した通知方法の種類によって異なります。単純な「N 秒ごとの ajax リクエスト」の場合、タスクが完了したかどうかを確認する AJAX リクエストを処理するビューを作成する必要があります。これを行う一般的な方法は、長時間実行されるタスクで、最後のステップとしてデータベースを更新することです。ステータスを確認するためのリクエストは、データベースのこの部分の更新を確認できます。
この方法を使用すると (長時間実行されるタスクを要求に合わせようとするのではなく)、いくつかの利点があります。
1.) 時間のかかる Web リクエストの処理は、(ブラウザーとサーバー以外に) タイムアウトになる可能性のあるポイントが複数あるため、注意が必要です。この方法を使用すると、すべての Web リクエストが非常に短くなり、タイムアウトする可能性が大幅に低くなります。
2.) Flask (およびそれに似た他のフレームワーク) は、Web クエリに応答できる特定の数のスレッドのみをサポートするように設計されています。8 つのスレッドがあると仮定します。そのうちの 4 つが長いリクエストを処理している場合、残りの 4 つのリクエストだけが、より一般的なリクエスト (ユーザーがプロファイル ページを取得するなど) を実際に処理します。Web サーバーの半分が、Web コンテンツを提供していない何かを実行している可能性があります。さらに悪いことに、8 つのスレッドすべてが長いプロセスを実行している可能性があります。つまり、いずれかのスレッドが終了するまで、サイトは Web リクエストに完全に応答できなくなります。
主な欠点: タスク キューを起動して実行するための設定作業が少し多くなり、システム全体が少し複雑になります。ただし、Web 上で長時間実行されるタスクには、この戦略を強くお勧めします。
これは、タイムアウトが小さいWebサーバー（ほとんどの場合Apache）が原因であると思います。この数を増やしてみてください
Apache の場合は、タイムアウト オプションを確認してください。
編集: Chrome でこのタイムアウトを設定することはできないと思います (本当に古いのですが、Google フォーラムでこのトピックを参照してください)。timeout. Internet Explorerについてはわかりません。
仮定しましょう：
これはサーバーの問題ではないため、Apache、nginx などのタイムアウト設定をいじる必要はありません。
遅延は、シナリオを管理しやすくするために、数時間または数日ではなく数分です。
ユーザーがサブミットする Web ページを制御し、そこからユーザー インタラクションを管理します。
それらが得られた場合は、標準の HTML フォーム送信を使用するのではなく、送信ボタンで JavaScript 関数を開始して処理を監視することをお勧めします。「しばらくお待ちください...少し時間がかかる場合があります」というスタイルのメッセージを表示し、jQuery.ajax を使用して、長いタイムアウト値で時間がかかるサーバーを呼び出します。jQuery のタイムアウトはミリ秒単位で測定されるため、60000 = 60 秒です。それよりも長い場合は、指定したタイムアウトをそれに応じて増やします。すべてのクライアントが非常に長いタイムアウトを許可するわけではないという報告を見てきました (たとえば、iOS の Safari には 60 秒の制限があるようです)。しかし、一般に、これにより、単純な Web フォームの送信に翻弄されるのではなく、対話 (ユーザーとの、低速のサーバーとの) を管理するためのプラットフォームが提供されます。
ここで考慮すべきいくつかのエッジケースがあります。Web サーバーのタイムアウトは、実際には上方に調整する必要がある場合があります (Apache のデフォルトは 300 秒、別名 5 分、nginx ではそれ以下、IIRC)。クライアントのタイムアウト (iOS など) の最大値が、発生している遅延に対して低すぎる可能性があります。これらのケースでは、サーバーで調整するか、別の対話戦略を採用する必要があります。しかし、AJAX で管理されたインタラクションから始めたいと思います。