Aspbufferlimit是否应该从4 MB的默认值开始增加？

Question

一位开发人员最近要求IIS 6中的Aspbufferlimit从4 MB的默认值增加到大约200 MB，用于流式传输较大的ZIP文件。

一段时间以前离开经典的ASP世界后，我一直在挠头，说明为什么要缓冲二进制文件并简单地建议设置 Response.Buffer = false. 。但是，您是否真的需要将其变为默认尺寸50倍？

显然，记忆消耗将是最大的担忧。更改此默认设置还有其他问题吗？

Answer 1

增加这样的缓冲区是一个极糟糕的主意。您将允许每个网站的每个访问者使用该量的RAM。如果你的 BinaryWrite/Response.Buffer=false 解决方案不安抚他，您也可以建议他打电话 Response.Flush() 时不时。两者都比增加缓冲区大小更可取。

实际上，除非您有很好的理由，否则您甚至不应该通过ASP处理器将其传递。将其写在预留此类内容的磁盘上的特殊位置，然后将其重定向。

Answer 2

关闭缓冲区的弊端之一（您可以使用冲洗，但我真的不明白您为什么在这种情况下这样做）是，客户不知道下载开始时的内容长度。因此，另一端的浏览器对话框不太有意义，它无法确定取得了多少进展。

更好的（IMO）替代方法是将所需的内容写入临时文件（也许使用文件名的GUID），然后将重定向发送到指向此临时文件的客户端。

这种方法更好的原因有很多： -

• 客户在接收数据的“保存对话框或应用程序”中获得良好的进度信息
• 某些应用程序可以充分利用字节范围获取，只有在服务器传递“静态”内容时才能很好地工作。
• 可以重新使用临时文件以使其他客户的请求满足请求

但是有很多缺点： -

• 如果需要一些时间来创建文件内容，则写入临时文件可以在收到数据之前留下一些延迟并增加下载时间。
• 如果在周围静态文件的内容上需要强大的安全性，则可能会担心，尽管使用随机GUID文件会减轻某种程度的方法
• 需要在旧临时文件上进行一些管家。