提高ASP性能的最佳选择第二部分（3）

    使用包含文件有什么影响？

　　ASP编程的一个重要功能就是包含来自其它页面的代码。通过这项功能，程序员可以在多个页面上共享函数，使代码更易于维护。缺点在于服务器必须从多个来源组装页面。以下是使用Include文件的两个测试。

　　使用内联代码的Include 文件

　　在这个测试中，有一小段代码被移到一个Include 文件中：

＜ ％ OPTION EXPLICIT
　　 Dim FirstName
　 　 …
　　 Dim BirthDate
　　 FirstName = "John"
　　 …
　　 BirthDate = "1/1/1950"
　　 ％ ＞

＜ !-- #include file="inc1.asp" -- ＞

　　/app2/include_1.asp片段

　　基准值 = 5.57 msec/page
　　 反应时间= 5.93 msec/page
　　 差 = +0.36 msec (6.5％ 增加)

　　这不奇怪。使用Include 文件形成了负载。

　　在函数区使用Include 文件

　　在这里，代码都包装在一个Include 文件中的子程序里。Include 引用是在页面顶部进行的，在ASP脚本的适当位置调用子程序。

＜ ％ OPTION EXPLICIT
　　 Dim FirstName
　　 …
　　 Dim BirthDate
　　 FirstName = "John"
　　 …
　　 BirthDate = "1/1/1950"
　　 CALL writeTable()
　　 ％ ＞

＜ !-- #include file="inc2.asp" -- ＞

　　/app2/include_2.asp片段

　　基准值 = 5.57 msec/page
　　 反应时间= 6.08 msec/page
　 差 =+0.51 msec (9.2％ 增加)

　　这对性能造成的影响比functions调用还大。因此：只有当代码在页面之间共享时才使用Include 文件。

    执行错误处理时会形成多大的负载？

　　对于所有真正的应用程序来说，错误处理都是必要的。这个测试中，通过调用On Error Resume Next函数来调用错误句柄。

＜ ％ OPTION EXPLICIT
　　 On Error Resume Next
　　 Dim FirstName
　　 …

/app2/error_1.asp片段

　　基准值 = 5.57 msec/page
　　 反应时间= 5.67 msec/page
　　 差= 0.10 msec (1.8％ 增加)

　　你可以看到，错误句柄带来了代价。我们可以提出以下建议：只有在会发生超出测试或控制能力之外的情况时才使用错误句柄。一个最基本的例子就是使用存取其它资源，如ADO或FileSystem 对象的COM对象。

    设置一个上下文处理是否对性能有影响？

　　当错误发生时，在页面上设置一个上下文处理允许脚本进行反转操作。这是通过在页面上使用处理声明来设置的。

＜ ％@ TRANSACTION = REQUIRED ％ ＞
　　 ＜ ％ OPTION EXPLICIT
　　 Dim FirstName
　　 …

/app2/transact1.asp片段

　　基准值 = 5.57 msec/page
　　 反应时间= 13.39 msec/page
　　 差 = +7.82 msec (140.4％ 增加)

　　啊！这真实最具有戏剧性的结果。所以请留意以下规则：只有当两个或更多操作被作为一个单元执行时，才使用处理上下文。