优化 ASP 应用程序和 VBScript 的技巧(6)

MyArray(5) = ?yet more stuff?
%>


最好一开始就将数组的初始大小 Dim 正确（在本例中，是 5）比 Redim 数组使其更大好得多。您可能浪费一些内存（如果您没有使用所有的元素），但获得的好处是速度变得更快。

技巧 14：使用响应缓冲
您可以通过启用“响应缓冲”，将要输出的一整页缓冲起来。这样就将写到浏览器的量减到最少，从而改善总体性能。每个写操作都会产生很大的系统开销（在 IIS 中以及在通过网络发送的数据量方面），因此写操作越少越好。由于其启动慢且使用 Nagling 算法（用来减轻网络塞车情况），TCP/IP 在发送一些大的数据块时比必须发送许多小的数据块时的效率高得多。

有两个方法启用响应缓冲。第一种，您可以使用 Internet Services Manager 为整个应用程序启用响应缓冲。我们建议采用这种方法，在 IIS 4.0 和 IIS 5.0 中默认为新的 ASP 应用程序启用响应缓冲。第二种，可以在每个 ASP 页面的接近顶端的地方加入下面的代码行，从而启用响应缓冲：

<% Response.Buffer = True %>


此代码行必须在任何响应数据被写到浏览器之前执行（即，在任何 HTML 出现在 ASP 脚本之前以及在使用 Response.Cookies 集合设置任何 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 语句
技巧 16：如果页面需要很长时间才能完成，那么执行前使用 Response.IsClientConnected
技巧 17：使用 <OBJECT> 标记例示对象
技巧 18：对于 ADO 和其它组件使用 TypeLib 绑定
技巧 19：利用浏览器的验证功能
技巧 20：避免在循环语句中使用字符串串联
技巧 21：启用浏览器和代理缓存
技巧 15：批处理内嵌脚本和 Response.Write 语句
VBScript 语法 <% = expression %> 将“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 页面。如果他们单击刷新或移到服务器上的另一个页面，在 ASP 请求队列的末尾就有一个新的请求等候，在队列的中间有一个断开连接的请求。当服务器的负载很高时（因此请求队列就会很长，响应时间也会相应地变长），就会经常发生这种情况，这样只能使情况变得更糟。如果用户不再连接，执行 ASP 页面（特别是慢的、大的 ASP 页面）已没有任何意义。您可以使用 Response.IsClientConnected 属性检查这一情况。如果它返回 False，则应调用 Response.End 并放弃页的其余部分。事实上，IIS 5.0 已将这一做法编为程序 - 每当 ASP 即将执行新请求时，它就会检查请求在队列中已等候了多长时间。如果已经在那里等候了多于 3 秒钟，ASP 将检查客户机是否仍处于连接状态，如果没有连接，就立即终止请求。您可以在配置数据库中使用 AspQueueConnectionTestTime 设置将超时时间由 3 秒调整为其它值。

如果页面要花很长时间才能执行完，也可以不时地检查 Response.IsClientConnected。当启用了响应缓冲时，最好不时地执行 Response.Flush，以用户知道，正在发生什么事。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有