这篇文章在 http://blog.51ait.cn/article.asp?id=357
但是，那里慢的掉牙，我打开花了半小时。而Google 搜索这篇文章，竟然只有那里有，其他地方没有。
我就把它转到这里了
原文如下：
Response.IsClientConnected 原理和用法
如果用户失去耐心，他们可以在开始执行他们的请求之前放弃 ASP 页。如果他们单击了 Refresh 或跳转到服务器的其他页上，在 ASP 请求队列的末尾将有一个新的请求，而在队列的中间有一个断开连接的请求。这通常发生在服务器处于高负荷的情况下（它有一个很长的请求队列，相应的响应时间也很长），这只能使情况更糟。如果用户不再连接，将没有执行 ASP 页的点（特别是低速、重量级的 ASP 页）。可以使用 response.IsClientConnected 属性检查这种情况。如果它返回 False ，则应调用 Response.End 并放弃该页的剩余内容。实际上，每当 ASP 要执行新的请求时，IIS 5.0 便将该方法编码，来检查队列中的请求有多长。如果在那里超过了 3 秒钟，ASP 会检查客户是否仍然连接着，如果客户已断开连接，就立即结束该请求。您可以使用 metabase 中的 AspQueueConnectionTestTime 设置，调整这 3 秒的超时时间。
如果有某页执行了很长时间，您可能还想按一定的时间间隔检查 Response.IsClientConnected 。在启用响应缓冲之后，按一定的时间间隔执行 Response.Flush ，告诉用户正在进行的是哪些事情，是个好办法。
注意 在 IIS 4.0 中， Response.IsClientConnected 将不能正常工作，除非首先执行 Response.Write 。如果启用了缓冲，也需要执行 Response.Flush 。在 IIS 5.0 中则不必如此 - Response.IsClientConnected 工作得很好。在任何情况下， Response.IsClientConnected 都要有些开销，所以，只有在执行至少要用 500 毫秒（如果想维持每秒几十页的吞吐量，这是一个很长的时间了）的操作前才使用它。作为通常的规则，不要在紧密循环的每次迭代中调用它，例如当绘制表中的行，可能每 20 行或每 50 行调用一次。