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

时间:2009-11-16 19:16:49

标签: iis asp-classic iis-metabase

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

前一段时间离开了经典ASP世界,我一直在想你为什么要缓冲BinaryWrite,只是建议设置Response.Buffer = false。但是,有没有你真的需要将其作为默认大小的50倍?

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

2 个答案:

答案 0 :(得分:2)

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

事实上,除非你有充分的理由,否则你甚至不应该通过asp处理器。将它写在磁盘上的特殊位置,为这些东西预留,然后重定向到那里。

答案 1 :(得分:1)

关闭缓冲区的一个缺点(你可以使用Flush,但我真的不明白为什么你会在这种情况下这样做)是客户端没有知道开头的内容长度是什么下载。因此,另一端的浏览器对话框没那么有意义,它无法说明已经取得了多大进展。

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

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

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

但是有一些缺点: -

  • 如果需要一段时间来创建文件内容,因此写入临时文件可能会在收到数据之前留下一些延迟并增加下载时间。
  • 如果需要强大的安全性,那么静态文件所在的内容可能会引起关注,尽管使用随机GUID文件名可以减轻这种影响
  • 需要对旧的临时文件进行一些内务管理。