AspBufferLimit 是否需要从默认的 4 MB 增加？答案

【问题标题】：Should AspBufferLimit ever need to be increased from the default of 4 MB?AspBufferLimit 是否需要从默认的 4 MB 增加？
【发布时间】：2009-11-16 19:16:49
【问题描述】：

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

前段时间离开 Classic ASP 世界后，我一直在摸不着头脑，为什么要缓冲 BinaryWrite 并简单地建议设置 Response.Buffer = false。但是在任何情况下您真的需要将其设置为默认大小的 50 倍吗？

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

【问题讨论】：

标签： iis asp-classic iis-metabase

【解决方案1】：

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

事实上，除非你有充分的理由，否则你甚至不应该通过 asp 处理器传递它。将其写入磁盘上为此类事情预留的特殊位置，然后重定向到那里。

【讨论】：

谢谢，忘了 `Response.Flush'。我也会传递它并在尝试后发布更新。
注意 Buffer = false 时，您仍然需要将在一次调用 BinaryWrite 时发送的数据量保持在 4MB 以下，如果使用 Flush，则需要在达到 4MB 限制之前调用 flush。跨度>
我有机会查看代码，您的假设是正确的：Buffer = False 已设置，但它正在执行单个 BinaryWrite。所以我建议使用查找并获取小于 4 MB 的文件块。

【解决方案2】：

关闭缓冲区的一个缺点（您可以使用 Flush，但我真的不明白您为什么要在这种情况下这样做）是客户端在开始时不了解内容长度下载。因此，另一端的浏览器对话框意义不大，它无法说明已经取得了多少进展。

更好的 (IMO) 替代方法是将所需内容写入临时文件（可能使用 GUID 作为文件名），然后向指向该临时文件的客户端发送重定向。

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

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

虽然有很多缺点：-

如果创建文件内容需要一些时间，因此写入临时文件可能会在接收数据之前留下一些延迟并增加下载时间。
如果需要对包含静态文件的内容进行强大的安全保护，则可能需要担心，尽管使用随机 GUID 文件名可以在一定程度上缓解这种情况
需要对旧的临时文件进行一些整理。

【讨论】：

不幸的是，安全要求不允许使用重定向到磁盘上的临时文件。