您现在的位置： 
bsp;下重新启动 IIS，Web 站点管理员需要使用工具，如 InetMon，来监视站点，如果服务器失败，将运行批处理文件来重新启动服务器。而 IIS 5.0 则引入了可靠的重新启动，它将自动重新启动失败的服务器。）
中级隔离。IIS 5.0 引入了这个新隔离级，它称为进程外的，这是因为 ASP 运行在 IIS 进程之外。在中级隔离中，所有被配置按“中级”运行的 ASP 应用程序，将共享单个进程空间。这将减少在一个服务器上运行多个进程外的 ASP 应用程序所需的进程数。中级是 IIS 5.0 中默认的隔离级。
高级隔离。在 IIS 4.0 和 IIS 5.0 中受到支持，高级隔离也是进程外的。如果 ASP 崩溃，则 Web 服务器并不崩溃。ASP 应用程序将在下一个 ASP 请求时自动重新启动。使用高级隔离，每个被配置为按高级运行的 ASP 应用程序，将在其自己的进程空间中运行。这样可以保护 ASP 应用程序彼此不受干扰。它的缺点是它需要为每个 ASP 应用程序建立独立的进程。当需要在一个服务器上主持十多个应用程序时，会增加很多开销。
那么，哪个选项是最好的呢？在 IIS 4.0 中，运行进程外的应用程序会极大地影响性能。在 IIS 5.0 中，做了许多工作，使得进程外运行 ASP 应用程序对性能产生的影响降到了最低。实际上，在大多数测试中，在 IIS 5.0 中的 ASP 进程外应用程序，要比 IIS 4.0 中的进程内应用程序运行得更快。无论如何，进程内（低隔离级）在两种平台上仍然产生了最好的性能。但是，如果您的命中率相对较低或最大吞吐量较低，选择低隔离级不会有太大的好处。所以，除非您需要每个 Web 服务器每秒处理数百或数千个页面，否则没有必要选择低隔离级。同样，应当测试多种配置并判断哪种情形最适合您。
注意： 当您进程外运行 ASP 应用程序（中级或高级隔离）时，则在 NT4 上它们将运行在 MTS 中，而在 Windows 2000 上它们将运行在 COM+ 中。即，在 NT4 上它们运行在 Mtx.exe 中，而在 Windows 2000 上它们运行在 DllHost.exe 中。在“任务管理器”中，您可以看见这些正在运行的进程。还可以看见 IIS 如何为进程外的 ASP 应用程序配置 MTS 程序包或 COM+ 应用程序。
COM 选项
COM 组件也有三个配置选项，虽然与 ASP 选项不完全相似。COM 组件可以被：“不配置”、配置为“库应用程序”或配置为“服务器应用程序”。“不配置”是指不向 COM+ 注册组件。组件将运行在调用者的进程空间，就是说，它们是“进程中”的。“库应用程序”也是进程中的，但受惠于 COM+ 的服务，包括安全性、事务和环境支持。“服务器应用程序”被配置为在其自己的进程空间中运行。
您可能看到，不配置的组件比库应用程序优点稍微多些。您还可能看到“库应用程序”比“服务器应用程序”有很大的性能优点。这是因为“库应用程序”与 ASP 运行在同一个进程中，而“服务器应用程序”则运行在自己的进程中。内部进程调用的开销要比进程内调用的开销大得多。而且，当在进程之间传递数据（如记录集）时，必须在两个进程之间复制所有的数据。
缺点！当使用“COM 服务器应用程序”时，如果要在 ASP 和 COM 之间传递对象，请确保对象实现“按值汇集”，即 MBV。实现 MBV 的对象将其自身从一个进程复制到另一个进程。这比另一种方式好，在另一种方式中，对象留在创建它的进程中，而其他进程则重复调用创建使用该对象的进程。被断开连接的 ADO 记录集将是按值汇集的，已连接的记录集则不是。Scripting.Dictionary 并不实现 MBV，不会在进程之间传递。最后，要另外告诉 VB 程序员的是：MBV 不是通过传递参数ByVal 获得的。MBV 是由原始组件创作者实现的。
怎么办？
如果您想要以性能与可靠性的合理交换来完成您的配置，我们的推荐如下：
在 IIS 4.0 上，使用 ASP 的低隔离级别，并使用“MTS 服务器包”。
在 IIS 5.0 上，使用 ASP 的中隔离级别，并使用“COM+ 库应用程序”。
这些是很一般的准则；通常让公司以中或高隔离级别运行 ASP，而单一目的的 Web 服务器可运行于低隔离级别。请权衡折中并自行决定满足需求的配置。
技巧 10：显式使用选项
在 .asp 文件中显式使用选项 Explicit。置于 .asp 文件开头的这一指令，强制开发人员声明所有要使用的变量。许多开发人员认为这有助于调试应用程序，因为它避免了错误键入变量名称而不经意地新建变量（例如，MyXLMString=... 而非 MyXMLString=)。
也许更重要的是，声明的变量比未声明的变量快。实际上，脚本运行时，在每次使用未声明变量时按照名称引用。而声明的变量，在编译或运行时分配了序号。这样，声明的变量按照该序号引用。由于选项 Explicit 强制变量声明，因此保证声明了所有变量而实现快速访问。
技巧 11：在子例程和函数中使用局部变量
局部变量是在子例程和函数中声明的变量。在子例程和函数中，局部变量访问要快于全局变量访问。使用局部变量还可以使代码更加清晰，因此尽可能使用局部变量。
技巧 12：将常用数据复制到脚本变量
在 ASP 中访问 COM 时，应该将常用的对象数据复制到脚本变量中。这将削减 COM 方法的调用，COM 方法的调用与访问脚本变量相比，要相对昂贵些。在访问 Collection 和 Dictionary 对象时，这一技术也可以削减了昂贵的查找。
通常，如果打算多次访问对象数据，请将数据放入脚本变量。该优化的主要目标是 Request 变量（Form 和 QueryString 变量）。例如，您的站点可能传递一个名为 UserID 的 QueryString。假定该 UserID 变量要在特定页中引用 12 次。请不要调用 Request("UserID") 12 次，而在 ASP 页的开头将 UserID 赋予某个变量。然后就在页中使用该变量。这将节省 11 次 COM 方法调用。
在实际中，访问 COM 属性或方法暗藏着繁复的过程和大量的开销。下面是一个示例，它只是些相当普通的代码（从语法上讲）：
Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...
在运行这段代码时，将发生下列事件：
变量 Foo 被解析为全局变量。
变量 bar 被解析为 Foo.的成员。这将产生 COM 方法调用。
变量 blah 被解析为 Foo.bar 的成员。这也将产生 COM 方法调用。
变量 qaz 被解析为 foo.bar.blah 的成员。是的，这也将产生 COM 方法调用。
调用 Foo.bar.blah.quaz(1)。又一次产生 COM 方法调用。理解这幅图了吗？
执行步骤 1 到 3 将再次解析 baz。系统不知道调用 qaz 是否更改对象模型，因此步骤 1 到 3 必须再次执行解析 baz。
将 baz 解析为 Foo.bar.blah 的成员。进行属性置入。
再次执行步骤 1 到 3 并解析 zaq。
再次执行步骤 1 到 3 并解析 abc。
正如所见，这是非常可怕的低效率（而且非常慢）。用 VBScript 编写该代码实现的快速方法为：
Set myobj = Foo.bar.blah ' 对 blah 做一次解析
Myobj.baz = myobj.qaz(1)
If Myobj.zaq = Myobj.abc Then '...
如果您使用的是 VBScript 5.0 或更高版本，则可用 With 语句来写这段代码：
With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With
请注意该技巧对 VB 编程同样有效。
技巧 13：避免重新定义数组
尽量避免 Redim 数组。从关心性能的角度来说，如果计算机受物理内存的限制，最好一开始将数组的维数设置为最差方案 - 而不要将维数设置为最佳方案，再根据需要重新定义维数。这并不意味着明知道不需要那么多而就是应该分配太多的内存。
下面代码展示了您没有必要地使用了Dim 和 Redim 来解决。
<%
Dim MyArray()
Redim MyArray(2)
MyArray(0) = "hello"
MyArray(1) = "good-bye"
MyArray(2) = "farewell"
...
' 一些别的代码中，这里您不需要更多的空间，然后 ...
Redim Preserve MyArray(5)
MyArray(3) = "more stuff"
MyArray(4) = "even more stuff"
MyArray(5) = "yet more stuff"
%>
更好的办法是只须一开始 Dim 数组为正确的大小（本例中为 5），而不是 Redim 数组，再加大数组。这可能会浪费一点儿内存（如果没有用尽所有元素），但是获得的是速度。
技巧 14：使用响应缓冲
您可以通过打开“响应缓冲区”来缓冲值得输出的整个页。这将写入浏览器的数据量降为最小，从而提高总体性能。每次写入都会有大量开销（包括 IIS 和通过电缆发送的数据量），因此写入的越少越好。TCP/IP 的工作效率，在发送少量大的数据块时明显高于发送大量小的数据块时，原因在于它的低速启动和 Nagling 算法（用于最小化网络阻塞）。
打开响应缓冲有两种方法。第一种，可以使用“Internet 服务管理器”为整个应用程序打开响应缓冲。这是推荐的方法，在 IIS 4.0 和 IIS 5.0 中，在默认情况下，为新的 ASP 应用程序打开响应缓冲。第二种，逐页将下列代码行放在 ASP 页的开头，从而启用响应缓冲：
<% Response.Buffer = True %>
该行代码必须在任何响应数据写入浏览器之前执行（也就是说，在任何 HTML 出现在 ASP 脚本中之前和任何 Cookies 被使用 Response.Cookies 集合设置之前）。通常，最好是为整个应用程序打开响应缓冲。这允许省略上面每页中的代码行。
Response.Flush
响应缓冲的通病是用户感觉 ASP 页响应迟钝（尽管总体响应时间改善了），因为他们需要等到整个页生成后才能看见该页。对于长时间运行的页面，可以通过设置 Response.Buffer = False 关闭响应缓冲。但是，更好的策略是使用 Response.Flush 方法。该方法刷新由 ASP 绘入浏览器的所有 HTML。例如，绘制了具有 1,000 行的表的 100 行后，ASP 可以调用 Response.Flush 强制将结果绘制到浏览器；这允许用户在其余的行准备好之前先看到头 100 行。该技术给了您两个举世无双的好东西 - 响应缓冲与浏览器中数据的逐步显示的组合。
（注意，在上面 1,000 行表的示例中，许多浏览器，在看到 </table> 结束标记之前不会开始绘制表。请检查目标浏览器的支持性。要解决该问题，请将表分割为具有较少行的多个表，然后在每个表后面调用 Response.Flush。新版本的 Internet Explorer 将在表完全下载之前绘制表，特别是如果指定表的列宽则绘制速度更快；这避免强制 Internet Explorer 通过度量每个单元格的内容来计算列宽。）
响应缓冲的另一个通病是在生成大型页时将使用服务器的大量内存。对于该问题，除了要求生成大型页的技巧外，还可以通过巧妙地使用 Response.Flush 来解决。
技巧 15：批处理内嵌脚本和 Response.Write 语句
VBScript 语法 <% = expression %> 将“表达式”的值写入 ASP 输出流。如果响应缓冲没有打开，则这些语句的每一句都会导致通过网络，以许多小型包的形式，向浏览器写入数据。这是非常慢的。另外，解释少量脚本和 HTML，将导致在脚本引擎和 HTML 之间切换，也降低了性能。因此，请使用下面技巧：用对 Response.Write 的一个调用，替换内嵌的密集组合表达式。例如，在下面范例中，每行每字段有一个对响应流的写入，每行都有许多 VBScript 和 HTML 之间的切换：
<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>
下面是更有效的代码，每行中有一个对响应流的写入。所有代码均包含在一个 VBScript 块内：
<table>
<%
For each fld in rs.Fields
Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf)
Next
While Not rs.EOF
Response.Write ("<tr>")
For Each fld in rs.Fields %>
Response.Write("<td>" & fld.Value & "</td>" & vbCrLf)
Next
Response.Write "</tr>"
Wend
%>
</table>
当响应缓冲被禁用时，本技巧的作用更大。最好启用响应缓冲，然后观察批处理 Response.Write 是否对性能有帮助。
（在这一特例中，构建表的主体的嵌套循环 (While Not rs.EOF...) 可以被精心构造的、对 GetString 的调用所替代。）
技巧 16：在开始长时间的任务之前先使用 Response.IsClientConnected
如果用户失去耐心，他们可以在开始执行他们的请求之前放弃 ASP 页。如果他们单击了 Refresh 或跳转到服务器的其他页上，在 ASP 请求队列的末尾将有一个新的请求，而在队列的中间有一个断开连接的请求。这通常发生在服务器处于高负荷的情况下（它有一个很长的请求队列，相应的响应时间也很长），这只能使情况更糟。如果用户不再连接，将没有执行 ASP 页的点（特别是低速、重量级的 ASP 页）。可以使用 Response.IsClientConnected 属性检查这种情况。如果它返回 False，则应调用 Response.End 并放弃该页的剩余内容。实际上，每当 ASP 要执行新的请求时，IIS 5.0 便将该方法编码，来检查队列中的请求有多长。如果在那里超过了 3 秒钟，ASP 会检查客户是否仍然连接着，如果客户已断开连接，就立即结束该请求。您可以使用 metabase 中的 AspQueueConnectionTestTime 设置，调整这 3 秒的超时时间。
如果有某页执行了
中级隔离。IIS 5.0 引入了这个新隔离级，它称为进程外的，这是因为 ASP 运行在 IIS 进程之外。在中级隔离中，所有被配置按“中级”运行的 ASP 应用程序，将共享单个进程空间。这将减少在一个服务器上运行多个进程外的 ASP 应用程序所需的进程数。中级是 IIS 5.0 中默认的隔离级。
高级隔离。在 IIS 4.0 和 IIS 5.0 中受到支持，高级隔离也是进程外的。如果 ASP 崩溃，则 Web 服务器并不崩溃。ASP 应用程序将在下一个 ASP 请求时自动重新启动。使用高级隔离，每个被配置为按高级运行的 ASP 应用程序，将在其自己的进程空间中运行。这样可以保护 ASP 应用程序彼此不受干扰。它的缺点是它需要为每个 ASP 应用程序建立独立的进程。当需要在一个服务器上主持十多个应用程序时，会增加很多开销。
那么，哪个选项是最好的呢？在 IIS 4.0 中，运行进程外的应用程序会极大地影响性能。在 IIS 5.0 中，做了许多工作，使得进程外运行 ASP 应用程序对性能产生的影响降到了最低。实际上，在大多数测试中，在 IIS 5.0 中的 ASP 进程外应用程序，要比 IIS 4.0 中的进程内应用程序运行得更快。无论如何，进程内（低隔离级）在两种平台上仍然产生了最好的性能。但是，如果您的命中率相对较低或最大吞吐量较低，选择低隔离级不会有太大的好处。所以，除非您需要每个 Web 服务器每秒处理数百或数千个页面，否则没有必要选择低隔离级。同样，应当测试多种配置并判断哪种情形最适合您。
注意： 当您进程外运行 ASP 应用程序（中级或高级隔离）时，则在 NT4 上它们将运行在 MTS 中，而在 Windows 2000 上它们将运行在 COM+ 中。即，在 NT4 上它们运行在 Mtx.exe 中，而在 Windows 2000 上它们运行在 DllHost.exe 中。在“任务管理器”中，您可以看见这些正在运行的进程。还可以看见 IIS 如何为进程外的 ASP 应用程序配置 MTS 程序包或 COM+ 应用程序。
COM 选项
COM 组件也有三个配置选项，虽然与 ASP 选项不完全相似。COM 组件可以被：“不配置”、配置为“库应用程序”或配置为“服务器应用程序”。“不配置”是指不向 COM+ 注册组件。组件将运行在调用者的进程空间，就是说，它们是“进程中”的。“库应用程序”也是进程中的，但受惠于 COM+ 的服务，包括安全性、事务和环境支持。“服务器应用程序”被配置为在其自己的进程空间中运行。
您可能看到，不配置的组件比库应用程序优点稍微多些。您还可能看到“库应用程序”比“服务器应用程序”有很大的性能优点。这是因为“库应用程序”与 ASP 运行在同一个进程中，而“服务器应用程序”则运行在自己的进程中。内部进程调用的开销要比进程内调用的开销大得多。而且，当在进程之间传递数据（如记录集）时，必须在两个进程之间复制所有的数据。
缺点！当使用“COM 服务器应用程序”时，如果要在 ASP 和 COM 之间传递对象，请确保对象实现“按值汇集”，即 MBV。实现 MBV 的对象将其自身从一个进程复制到另一个进程。这比另一种方式好，在另一种方式中，对象留在创建它的进程中，而其他进程则重复调用创建使用该对象的进程。被断开连接的 ADO 记录集将是按值汇集的，已连接的记录集则不是。Scripting.Dictionary 并不实现 MBV，不会在进程之间传递。最后，要另外告诉 VB 程序员的是：MBV 不是通过传递参数ByVal 获得的。MBV 是由原始组件创作者实现的。
怎么办？
如果您想要以性能与可靠性的合理交换来完成您的配置，我们的推荐如下：
在 IIS 4.0 上，使用 ASP 的低隔离级别，并使用“MTS 服务器包”。
在 IIS 5.0 上，使用 ASP 的中隔离级别，并使用“COM+ 库应用程序”。
这些是很一般的准则；通常让公司以中或高隔离级别运行 ASP，而单一目的的 Web 服务器可运行于低隔离级别。请权衡折中并自行决定满足需求的配置。
技巧 10：显式使用选项
在 .asp 文件中显式使用选项 Explicit。置于 .asp 文件开头的这一指令，强制开发人员声明所有要使用的变量。许多开发人员认为这有助于调试应用程序，因为它避免了错误键入变量名称而不经意地新建变量（例如，MyXLMString=... 而非 MyXMLString=)。
也许更重要的是，声明的变量比未声明的变量快。实际上，脚本运行时，在每次使用未声明变量时按照名称引用。而声明的变量，在编译或运行时分配了序号。这样，声明的变量按照该序号引用。由于选项 Explicit 强制变量声明，因此保证声明了所有变量而实现快速访问。
技巧 11：在子例程和函数中使用局部变量
局部变量是在子例程和函数中声明的变量。在子例程和函数中，局部变量访问要快于全局变量访问。使用局部变量还可以使代码更加清晰，因此尽可能使用局部变量。
技巧 12：将常用数据复制到脚本变量
在 ASP 中访问 COM 时，应该将常用的对象数据复制到脚本变量中。这将削减 COM 方法的调用，COM 方法的调用与访问脚本变量相比，要相对昂贵些。在访问 Collection 和 Dictionary 对象时，这一技术也可以削减了昂贵的查找。
通常，如果打算多次访问对象数据，请将数据放入脚本变量。该优化的主要目标是 Request 变量（Form 和 QueryString 变量）。例如，您的站点可能传递一个名为 UserID 的 QueryString。假定该 UserID 变量要在特定页中引用 12 次。请不要调用 Request("UserID") 12 次，而在 ASP 页的开头将 UserID 赋予某个变量。然后就在页中使用该变量。这将节省 11 次 COM 方法调用。
在实际中，访问 COM 属性或方法暗藏着繁复的过程和大量的开销。下面是一个示例，它只是些相当普通的代码（从语法上讲）：
Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...
在运行这段代码时，将发生下列事件：
变量 Foo 被解析为全局变量。
变量 bar 被解析为 Foo.的成员。这将产生 COM 方法调用。
变量 blah 被解析为 Foo.bar 的成员。这也将产生 COM 方法调用。
变量 qaz 被解析为 foo.bar.blah 的成员。是的，这也将产生 COM 方法调用。
调用 Foo.bar.blah.quaz(1)。又一次产生 COM 方法调用。理解这幅图了吗？
执行步骤 1 到 3 将再次解析 baz。系统不知道调用 qaz 是否更改对象模型，因此步骤 1 到 3 必须再次执行解析 baz。
将 baz 解析为 Foo.bar.blah 的成员。进行属性置入。
再次执行步骤 1 到 3 并解析 zaq。
再次执行步骤 1 到 3 并解析 abc。
正如所见，这是非常可怕的低效率（而且非常慢）。用 VBScript 编写该代码实现的快速方法为：
Set myobj = Foo.bar.blah ' 对 blah 做一次解析
Myobj.baz = myobj.qaz(1)
If Myobj.zaq = Myobj.abc Then '...
如果您使用的是 VBScript 5.0 或更高版本，则可用 With 语句来写这段代码：
With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With
请注意该技巧对 VB 编程同样有效。
技巧 13：避免重新定义数组
尽量避免 Redim 数组。从关心性能的角度来说，如果计算机受物理内存的限制，最好一开始将数组的维数设置为最差方案 - 而不要将维数设置为最佳方案，再根据需要重新定义维数。这并不意味着明知道不需要那么多而就是应该分配太多的内存。
下面代码展示了您没有必要地使用了Dim 和 Redim 来解决。
<%
Dim MyArray()
Redim MyArray(2)
MyArray(0) = "hello"
MyArray(1) = "good-bye"
MyArray(2) = "farewell"
...
' 一些别的代码中，这里您不需要更多的空间，然后 ...
Redim Preserve MyArray(5)
MyArray(3) = "more stuff"
MyArray(4) = "even more stuff"
MyArray(5) = "yet more stuff"
%>
更好的办法是只须一开始 Dim 数组为正确的大小（本例中为 5），而不是 Redim 数组，再加大数组。这可能会浪费一点儿内存（如果没有用尽所有元素），但是获得的是速度。
技巧 14：使用响应缓冲
您可以通过打开“响应缓冲区”来缓冲值得输出的整个页。这将写入浏览器的数据量降为最小，从而提高总体性能。每次写入都会有大量开销（包括 IIS 和通过电缆发送的数据量），因此写入的越少越好。TCP/IP 的工作效率，在发送少量大的数据块时明显高于发送大量小的数据块时，原因在于它的低速启动和 Nagling 算法（用于最小化网络阻塞）。
打开响应缓冲有两种方法。第一种，可以使用“Internet 服务管理器”为整个应用程序打开响应缓冲。这是推荐的方法，在 IIS 4.0 和 IIS 5.0 中，在默认情况下，为新的 ASP 应用程序打开响应缓冲。第二种，逐页将下列代码行放在 ASP 页的开头，从而启用响应缓冲：
<% Response.Buffer = True %>
该行代码必须在任何响应数据写入浏览器之前执行（也就是说，在任何 HTML 出现在 ASP 脚本中之前和任何 Cookies 被使用 Response.Cookies 集合设置之前）。通常，最好是为整个应用程序打开响应缓冲。这允许省略上面每页中的代码行。
Response.Flush
响应缓冲的通病是用户感觉 ASP 页响应迟钝（尽管总体响应时间改善了），因为他们需要等到整个页生成后才能看见该页。对于长时间运行的页面，可以通过设置 Response.Buffer = False 关闭响应缓冲。但是，更好的策略是使用 Response.Flush 方法。该方法刷新由 ASP 绘入浏览器的所有 HTML。例如，绘制了具有 1,000 行的表的 100 行后，ASP 可以调用 Response.Flush 强制将结果绘制到浏览器；这允许用户在其余的行准备好之前先看到头 100 行。该技术给了您两个举世无双的好东西 - 响应缓冲与浏览器中数据的逐步显示的组合。
（注意，在上面 1,000 行表的示例中，许多浏览器，在看到 </table> 结束标记之前不会开始绘制表。请检查目标浏览器的支持性。要解决该问题，请将表分割为具有较少行的多个表，然后在每个表后面调用 Response.Flush。新版本的 Internet Explorer 将在表完全下载之前绘制表，特别是如果指定表的列宽则绘制速度更快；这避免强制 Internet Explorer 通过度量每个单元格的内容来计算列宽。）
响应缓冲的另一个通病是在生成大型页时将使用服务器的大量内存。对于该问题，除了要求生成大型页的技巧外，还可以通过巧妙地使用 Response.Flush 来解决。
技巧 15：批处理内嵌脚本和 Response.Write 语句
VBScript 语法 <% = expression %> 将“表达式”的值写入 ASP 输出流。如果响应缓冲没有打开，则这些语句的每一句都会导致通过网络，以许多小型包的形式，向浏览器写入数据。这是非常慢的。另外，解释少量脚本和 HTML，将导致在脚本引擎和 HTML 之间切换，也降低了性能。因此，请使用下面技巧：用对 Response.Write 的一个调用，替换内嵌的密集组合表达式。例如，在下面范例中，每行每字段有一个对响应流的写入，每行都有许多 VBScript 和 HTML 之间的切换：
<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>
下面是更有效的代码，每行中有一个对响应流的写入。所有代码均包含在一个 VBScript 块内：
<table>
<%
For each fld in rs.Fields
Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf)
Next
While Not rs.EOF
Response.Write ("<tr>")
For Each fld in rs.Fields %>
Response.Write("<td>" & fld.Value & "</td>" & vbCrLf)
Next
Response.Write "</tr>"
Wend
%>
</table>
当响应缓冲被禁用时，本技巧的作用更大。最好启用响应缓冲，然后观察批处理 Response.Write 是否对性能有帮助。
（在这一特例中，构建表的主体的嵌套循环 (While Not rs.EOF...) 可以被精心构造的、对 GetString 的调用所替代。）
技巧 16：在开始长时间的任务之前先使用 Response.IsClientConnected
如果用户失去耐心，他们可以在开始执行他们的请求之前放弃 ASP 页。如果他们单击了 Refresh 或跳转到服务器的其他页上，在 ASP 请求队列的末尾将有一个新的请求，而在队列的中间有一个断开连接的请求。这通常发生在服务器处于高负荷的情况下（它有一个很长的请求队列，相应的响应时间也很长），这只能使情况更糟。如果用户不再连接，将没有执行 ASP 页的点（特别是低速、重量级的 ASP 页）。可以使用 Response.IsClientConnected 属性检查这种情况。如果它返回 False，则应调用 Response.End 并放弃该页的剩余内容。实际上，每当 ASP 要执行新的请求时，IIS 5.0 便将该方法编码，来检查队列中的请求有多长。如果在那里超过了 3 秒钟，ASP 会检查客户是否仍然连接着，如果客户已断开连接，就立即结束该请求。您可以使用 metabase 中的 AspQueueConnectionTestTime 设置，调整这 3 秒的超时时间。
如果有某页执行了
