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

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

不久前，我离开了传统的ASP世界，我一直在琢磨为什么要缓冲BinaryWrite，只是建议设置

Response.buffer=false

。但是，在任何情况下，您真的需要将其设置为默认大小的50倍吗

---

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

这样增加缓冲区是一个非常糟糕的主意。您将允许每个访问您的站点的访问者使用多达该数量的ram。如果您的

BinaryWrite/Response.Buffer=false

解决方案不能让他满意，您还可以建议他不时调用

Response.Flush（）

。两者都比增加缓冲区大小更可取

---

事实上，除非你有一个很好的理由，你甚至不应该通过asp处理器传递这个。将它写到磁盘上为这些事情留出的一个特殊位置，然后重定向到那里。

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

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

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

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

但也有一些不利因素：-

• 如果创建文件内容需要一些时间，那么写入临时文件可能会在接收数据之前留下一些延迟，从而增加下载时间
• 如果在内容上需要强大的安全性，则可能需要考虑静态文件，尽管使用随机GUID文件名在一定程度上缓解了这一问题
• 需要对旧的临时文件进行整理

---

谢谢，忘了“Response.Flush”。我也会将其传递，并在尝试更新后发布更新。注意，如果Buffer=false，您仍然需要将一次调用BinaryWrite发送的数据量保持在4MB以下，如果使用Flush，则需要在达到4MB限制之前调用Flush。我有机会查看代码，您的假设是正确的：

Buffer=False

已设置，但它正在执行单个二进制写入。所以我建议使用小于4MB的seek和get文件块。不幸的是，安全要求阻止了重定向到磁盘上临时文件的使用。