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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

但是有很多缺点：-

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