让asp逐行输出缓存(Response.flush),实时显示进度
写程序的人在编写由asp页面生成静态页面html的时候，如果同时生成大量页面，一定遇到过浏览器下方的进度条上显示着3%，6%，10%等缓慢增长的漫长等待过程。在这个等待过程中，你不知道页面已经生成到哪一条记录，只能大眼瞪小眼的等。
如果你知道Response.Flush和Response.Clear，那你就可以不用这样的等待了。每生成一个Html页面，就用Response.write立即返回一条信息，提示该条数据库记录已经生成Html。
这样，在同时生成大量页面的时候，你就不再是孤独的望着一片空白的页面而只是浏览器下方缓慢变化着的进度条而发呆了，你可以随时知道当前已经生成到哪条数据库记录了，即使出现意外，如死机，断电等，你也知道下次生成应该从哪天记录重新开始生成html了。是不是很爽呢，这就是一个进度条了而且更具体了。
呵呵，别着急，我们先来看Response.Flush和Response.Clear的意思吧。
Response对象之Flush方法，立即发送缓冲区中的输出。如果未将 Response.Buffer 设置为 TRUE，则该方法将导致运行时错误。语法：Response.Flush；注释：如果在 ASP 页上调用 Flush 方法，则服务器将响应该页上保持活动的请求。应用于Response对象。
关于Buffer，这里有段介绍。Buffer从英文直译过来的意思是“缓冲区”，这里我们将它称为缓冲，因为它不仅是个名词，还是个动词。
缓冲区是存储一系列的数据的地方，客户端所获得的数据可以从程序的执行结果直接输出，也可以从缓冲区输出。但是这两种方式在速度上是有差异的：在web中，当一个asp程序被请求的次数不多时，二者基本上没有什么差异，至少我们感觉不出来。但是当有很多人请求一个asp程序时，速度可就不一样了。如果没有缓冲区，那么每个请求asp程序的人的客户端所得到的结果都是asp程序执行一次所得到的结果，而如果预先将asp程序缓冲，那么每个客户端所得到的结果就是缓冲区的结果，不是执行一次程序的结果。比如有1000个用户同时访问一个asp页面，如果这个asp程序没有缓冲，那么程序将被执行一千次，这样服务器的负荷就回加大，从而导致客户端打开页面速度变慢；如果这个asp程序被缓冲了，那么结果就不一样了，每个客户端直接从缓冲区获得数据，服务器将不会因为访问增加而增加程序执行次数，因此客户端打开页面的速度也就比上一种情况要快。这就是Buffer的好处。
关于Response.clear，Clear 方法删除缓冲区中的所有 HTML 输出。但 Clear 方法只删除响应正文而不删除响应标题。可以用该方法处理错误情况。请注意，如果未将 Response.Buffer 设置为 TRUE，则该方法将导致运行时错误。语法：Response.Clear；应用于Response对象。
好了，想实现立即输出的效果，只要在循环体内的希望输出提示信息后加上Response.Flush和Response.Clear就可以了。如：
<%
for i=1 to 2000
for i1=1 to 3000
''空循环，延长每次执行时间
next
Response.write i&")"
Response.Flush
Response.Clear
next
%>
上述asp语句，你执行后，会发现输出是逐个逐个输出的，执行一次，就输出一次。
但我在网上看到有人说，“很多时候，我们发现即使我们使用了Response.Flush()，但是并没有将前面的信息发到客户端来显示。呈献给我们的依然是白屏。经过反复的测试，我得出一个结论：就是flush的内容至少要有256字节。也就是只有编译产生了至少256字节的数据，才能在执行Response.Flush()以后将信息发到客户端并显示。”
很奇怪，上述我给出的语句确确实实是实现了逐个显示的效果的，并没有事先输出256个字节，大家可以把上述语句另存为记事本运行看看，效果是逐行显示的。本人所列观点，仅代表flymorn个人观点，不挪作他用。
如果你确实需要事先输出256个字节，可以如下：
<%
dim liji
for i=1 to 256
liji=liji&"<!--先产生256个字符-www.devdao.com-->"
if len(liji)>=256 then exit for
next
%>
最新评论