1

仲間の開発者は最近、IIS6のAspBufferLimitをデフォルト値の4MBから約200MBに増やして、より大きなZIPファイルをストリーミングするように要求しました。

しばらく前にClassicASPの世界を離れたので、BinaryWriteをバッファリングする理由について頭を悩ませていましたが、単に設定を提案しResponse.Buffer = falseました。しかし、実際にデフォルトサイズの50倍にする必要がある場合はありますか？

明らかに、メモリ消費が最大の懸念事項になります。このデフォルト設定の変更に関して他に懸念事項はありますか？

4

2 に答える 2

2

そのようにバッファを増やすことは、非常に悪い考えです。あなたはあなたのサイトへのすべての訪問者がその量までのRAMを使用することを許可するでしょう。あなたのBinaryWrite/Response.Buffer=false解決策が彼をなだめないなら、あなたは彼が時々電話することを提案することもできますResponse.Flush()。バッファサイズを増やすよりもどちらかが望ましいでしょう。

実際、非常に正当な理由がない限り、これをaspプロセッサに渡すことすらすべきではありません。そのようなもののために取っておいたディスク上の特別な場所にそれを書いて、代わりにそこにリダイレクトしてください。

于 2009-11-16T19:22:01.763 に答える
1

バッファをオフにすることの欠点の1つ（フラッシュを使用することはできますが、このシナリオでそれを行う理由がわかりません）は、クライアントがダウンロードの開始時にコンテンツの長さを学習しないことです。したがって、もう一方の端にあるブラウザダイアログはあまり意味がなく、どれだけ進歩したかを知ることはできません。

より良い（IMO）代替手段は、目的のコンテンツを一時ファイルに書き込み（おそらく、ファイル名にGUIDを使用して）、この一時ファイルを指すクライアントにリダイレクトを送信することです。

このアプローチが優れている理由はいくつかあります。-

  • クライアントは、データを受信する保存ダイアログまたはアプリケーションで適切な進捗情報を取得します
  • 一部のアプリケーションは、サーバーが「静的」コンテンツを配信している場合にのみ適切に機能するバイト範囲フェッチをうまく利用できます。
  • 一時ファイルは、他のクライアントからの要求を満たすために再利用できます

ただし、いくつかの欠点があります。-

  • したがって、ファイルコンテンツの作成に時間がかかる場合、一時ファイルへの書き込みにより、データが受信されるまでにある程度の遅延が残り、ダウンロード時間が長くなる可能性があります。
  • 静的ファイルが存在するコンテンツに強力なセキュリティが必要な場合は、ランダムなGUIDファイル名を使用することで多少緩和されますが、問題になる可能性があります。
  • 古い一時ファイルのハウスキーピングが必要です。
于 2009-11-17T16:13:05.283 に答える