Should AspBufferLimit ever need to be increased from the default of 4 MB?

Question

A fellow developer recently requested that the AspBufferLimit in IIS 6 be increased from the default value of 4 MB to around 200 MB for streaming larger ZIP files.

Having left the Classic ASP world some time ago, I was scratching my head as to why you'd want to buffer a BinaryWrite and simply suggested setting Response.Buffer = false. But is there any case where you'd really need to make it 50x the default size?

Obviously, memory consumption would be the biggest worry. Are there other concerns with changing this default setting?

Answer 1

Increasing the buffer like that is a supremely bad idea. You would allow every visitor to your site to use up to that amount of ram. If your BinaryWrite/Response.Buffer=false solution doesn't appease him, you could also suggest that he call Response.Flush() now and then. Either would be preferable to increasing the buffer size.

In fact, unless you have a very good reason you shouldn't even pass this through the asp processor. Write it to a special place on disk set aside for such things and redirect there instead.

Answer 2

One of the downsides of turning off the buffer (you could use Flush but I really don't get why you'd do that in this scenario) is that the Client doesn't learn what the Content length at the start of the download. Hence the browsers dialog at the other end is less meaningfull, it can't tell how much progress has been made.

A better (IMO) alternative is to write the desired content to a temporary file (perhaps using GUID for the file name) then sending a Redirect to the client pointing at this temporary file.

There are a number of reasons why this approach is better:-

• The client gets good progress info in the save dialog or application receiving the data
• Some applications can make good use of byte range fetches which only work well when the server is delivering "static" content.
• The temporary file can be re-used to satisify requests from other clients

There are a number of downside though:-

• If takes sometime to create the file content, writing to a temporary file can therefore leave some latency before data is received and increasing the download time.
• If strong security is needed on the content having a static file lying around may be a concern although the use of a random GUID filename mitigates that somewhat
• There is need for some housekeeping on old temporary files.