Response.Flush と Response.Clear を知っている場合は、このように待つ必要はありません。 HTML ページが生成されるたびに、Response.write を使用して、データベース レコードが HTML を生成したことを示すメッセージが即座に返されます。プログラマーが ASP ページから生成された静的ページ HTML を作成するときに、多数のページが同時に生成されると、ブラウザーの下のプログレス バーに 3%、6%、10 と表示される長い待機プロセスが発生したことがあるはずです。 %など、徐々に増加します。この待機プロセス中は、ページ上にどのレコードが生成されたかわからないため、目を大きく見開いて待つことしかできません。
Response.Flush と Response.Clear を知っている場合は、このように待つ必要はありません。 HTML ページが生成されるたびに、Response.write を使用して、データベース レコードが HTML を生成したことを示すメッセージが即座に返されます。
このようにして、多数のページが同時に生成された場合でも、空白のページを一人で見るのではなく、ブラウザの下部にあるゆっくりと変化する進行状況バーをいつでも確認することができます。クラッシュや停電などの事故が発生した場合でも、次の世代を記録して HTML の生成を再開する必要がある日付がわかります。これは進行状況バーであり、より具体的です。
あはは、心配しないで、まず Response.Flush と Response.Clear の意味を見てみましょう。
Response オブジェクトの Flush メソッドは、バッファ内の出力を直ちに送信します。 Response.Buffer が TRUE に設定されていない場合、このメソッドは実行時エラーを引き起こします。構文: Response.Flush; 注: ASP ページで Flush メソッドが呼び出された場合、サーバーはページ上のキープアライブ要求に応答します。応答オブジェクトに適用されます。
Buffer については、こちらでご紹介します。バッファは英語から直訳するとバッファゾーンです。名詞だけでなく動詞でもあるため、ここではバッファと呼びます。
バッファは一連のデータを格納する場所で、クライアントが取得したデータはプログラムの実行結果から直接出力したり、バッファから出力したりすることができます。ただし、これら 2 つの方法には速度の違いがあります。Web では、ASP プログラムが何度もリクエストされない場合、基本的に 2 つの方法に違いはありません。少なくとも私たちはそれを感じられません。しかし、多くの人がASPプログラムをリクエストすると、速度が異なります。バッファがない場合、ASP プログラムを要求した各クライアントが取得する結果は、ASP プログラムを 1 回実行して取得した結果になります。ASP プログラムが事前にバッファリングされている場合、各クライアントが取得した結果はバッファリングされた結果になります。この領域の結果は、プログラムを 1 回実行した結果ではありません。たとえば、1,000 人のユーザーが同時に ASP ページにアクセスすると、ASP プログラムがバッファリングされていない場合、プログラムは 1,000 回実行されるため、サーバーの負荷が増加し、クライアントがページを開く速度が遅くなります。 ASP プログラムがバッファリングされている場合、結果は異なります。各クライアントはバッファから直接データを取得します。また、サーバーはアクセスの増加によってプログラムの実行数を増やすことがないため、クライアントがページを開く速度は遅くなります。前の場合よりも遅くなります。これはバッファの利点です。
Response.clear に関しては、Clear メソッドはバッファ内のすべての HTML 出力を削除します。ただし、Clear メソッドは応答本文のみを削除し、応答ヘッダーは削除しません。このメソッドを使用してエラー状態を処理できます。 Response.Buffer が TRUE に設定されていない場合、このメソッドは実行時エラーを引き起こすことに注意してください。構文: Response.Clear; Response オブジェクトに適用されます。
即時出力の効果を実現したい場合は、ループ本体内の目的の出力プロンプト情報の後に Response.Flush と Response.Clear を追加するだけです。のように：
<%
i=1 ～ 2000 の場合
i1=1～3000の場合
'' 空のループ、各実行時間を延長
次
Response.write i&)
レスポンス.フラッシュ
応答.クリア
次
%>
上記のaspステートメントを実行すると、1回実行すると1回ずつ出力されることがわかります。
しかし、インターネット上で誰かが、Response.Flush() を使用しても、以前の情報が表示のためにクライアントに送信されないことが何度もある、と言っているのを目にしました。まだ白い画面が表示されます。テストを繰り返した結果、フラッシュ コンテンツは少なくとも 256 バイトでなければならないという結論に達しました。つまり、コンパイルで少なくとも 256 バイトのデータが生成された場合にのみ、情報をクライアントに送信し、Response.Flush() の実行後に表示できます。
上記のステートメントが実際に 1 つずつ表示する効果を実現しており、事前に 256 バイトを出力していないのは奇妙です。上記のステートメントをメモ帳として保存して実行すると、その効果が 1 行ずつ表示されます。私がリストした意見はフライモーンの個人的な意見のみを表すものであり、他の目的に使用することはできません。
本当に事前に 256 バイトを出力する必要がある場合は、次のようにすることができます。
<%
薄暗いリジ
i=1 ～ 256 の場合
liji=liji&<!--最初に 256 文字を生成します-WWW.PIAOYI.ORG-->
len(liji)>=256 の場合は終了します。
次
%>
異なる見解や異なる検査結果がございましたら、お気軽にご相談ください。