提高ASP性能的最佳选择

作者:CSDN

来源:CSDN

热度:

2008-2-21 11:06:03

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

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

　　使用内联代码的Include 文件

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

　　<% OPTION EXPLICIT 
　　 Dim FirstName 
　 　 … 
　　 Dim BirthDate 
　　 FirstName = "John" 
　　 … 
　　 BirthDate = "1/1/1950" 
　　 %>

　　/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() 
　　 %>

　　/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% 增加)

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

我来说两句：