如果页面需要很长时间才能完成，那么执行前使用

　　Response.IsClientConnected
　　如果用户性急，他们可能会在您开始执行他们的请求之前，就会放弃 ASP 页面。如果他们单击刷新或移到服务器上的另一个页面，在 ASP 请求队列的末尾就有一个新的请求等候，在队列的中间有一个断开连接的请求。当服务器的负载很高时（因此请求队列就会很长，响应时间也会相应地变长），就会经常发生这种情况，这样只能使情况变得更糟。如果用户不再连接，执行 ASP 页面（特别是慢的、大的 ASP 页面）已没有任何意义。您可以使用 Response.IsClientConnected 属性检查这一情况。如果它返回 False，则应调用 Response.End 并放弃页的其余部分。事实上，IIS 5.0 已将这一做法编为程序 - 每当 ASP 即将执行新请求时，它就会检查请求在队列中已等候了多长时间。如果已经在那里等候了多于 3 秒钟，ASP 将检查客户机是否仍处于连接状态，如果没有连接，就立即终止请求。您可以在配置数据库中使用 AspQueueConnectionTestTime 设置将超时时间由 3 秒调整为其它值。
　　如果页面要花很长时间才能执行完，也可以不时地检查 Response.IsClientConnected。当启用了响应缓冲时，最好不时地执行 Response.Flush，以用户知道，正在发生什么事。
　　注意 在 IIS 4.0 上，除非先执行了 Response.Write，否则 Response.IsClientConnected 就不能正常工作。如果启用了缓冲，您也必须执行 Response.Flush。在 IIS 5.0 上，却没有必要这样做，- Response.IsClientConnected 工作正常。在任何情况下，Response.IsClientConnected 都会有一些开销，因此只有在一个操作至少要花（比方说） 500 毫秒（如果您想维持每秒钟数十页的吞吐量，这是一个很长的时间）才使用它。经验表明，不要每次重复执行紧密循环时都调用它，如显示表的许多行时 - 每隔二十或五十行调用一次可能比较合适。
　　许多人在循环中建立一个字符串，就象下面的样子：
　　s = "<table>" & vbCrLf
　　For Each fld in rs.Fields
　　s = s & " <th>" & fld.Name & "</th> "
　　Next
　　While Not rs.EOF
　　s = s & vbCrLf & " <tr>"
　　For Each fld in rs.Fields
　　s = s & " <td>" & fld.Value & "</td> "
　　Next
　　s = s & " </tr>"
　　rs.MoveNext
　　Wend
　　s = s & vbCrLf & "</table>" & vbCrLf
　　Response.Write s
　　这存在几个问题。首先是重复的连接字符串消耗二次方的时间，而且，运行的时间与计算的字段数量也是平方的关系。下面的简单例子更清楚地说明这一点：
　　s = ""
　　For i = Asc("A") to Asc("Z")
　　s = s & Chr(i)
　　Next
　　在第1层循环时，S的值是“A”；第2层循环时，VBScript要重新分配字符串，拷贝了2个字符（“AB”）到S中；第3层循环时，需要再重新分配并且拷贝3个字符到S中。在第N层循环时，就需要重新分配并拷贝N个字符到S中。那就是1+2+3+...+N的总和，也就是N*（N＋1）/2个拷贝。
　　在上面的记录集例子中，如果有100个记录和5个字段，内部循环就要执行100*5＝500次，并且，完成所有拷贝和再分配任务的时间将接近500*500＝250，000。这还是一个适当尺寸记录集的拷贝工作。
　　在这个例子中，可以通过替换字符串连接为Response.Write（）或者行内脚本（< % =fld.Value % >）的方法提高程序性能。如果response buffering打开（也应该打开），这将很快，因为Response.Write仅仅附加数据在缓冲区的尾部，而且不需要再分配。
　　如果用JScript连接字符串，强烈建议使用“＋＝”操作符，就是说，使用s＋＝“字符串”，而不是s ＝ s＋“字符串”。