浅谈如何增强ASP程序性能

来源:互联网 时间:1970-01-01

Session在繁忙站点上使用时有几个缺陷。繁忙的意思是:站点上每秒有上百的页面被请求,或者同时有上千的访问用户。这个技巧对于那些要求水平扩展强 的站点非常重要,也就是指这些站点:它们利用多个服务器完成数据装载或者处理大量容错。对于小型站点,比如内部网Intranet,Session是非常 值得提倡的。

        再次重申,ASP自动地为每一个首次点击Web服务器的用户创建一个Session,每一个Session占有大约10KB的内存,生存期默认是20分钟。

        使用Session最大的问题不是性能,而是扩展性,Session不能跨越多个Web服务器,一旦在一个服务器上创建了Session,它的数据就驻留 在那里。这意味着,如果在Web上使用Session,你就得为每一个直接访问存放Session服务器的用户请求设计一个策略。这就是将用户'粘'在 Web服务器上,术语'sticky sessions'就来源于此。如果Web服务器遇到障碍,'Stuck'用户就会丢失他们的Session状态,因为Session不保留在磁盘上。
        许多对任务要求严格的站点都要设立至少2个Web服务器,所以在设计严格任务的应用程序时,就需要执行'sticky sessions',或者简单地避免使用Session,同时也可以采取其他保存用户状态到独立Web服务器的管理技术。

如果不使用Session,一定要确认将它们关闭,这可以通过Internet服务管理器实现。如果决定使用Session,可以通过几种方法来最小化它们的影响。

        可以将不需要Session的内容(比如帮助画面,访问者区域,等等)移动到关闭Session的独立ASP应用程序中。在基础页面上,可以给ASP一个指示,让它不需要使用Session。将下面的代码直接加入到ASP页面的头部:

<% @EnableSessionState=False %>

        使用这个指示的一个很好的解释是在框架结构中Session创建了一个有趣的问题。ASP确保在一个时刻只有一个来自Session的请求被执行,这就确 保了如果浏览器为单个用户请求多个页面时,只有一个ASP请求在那时能够接受Session,如此就避免了存取Session对象时的多线程问题。很不 幸,在框架结构中的所有页面将按照连续的顺序显示出来,一个接一个,而不是同时,所以用户为了看到整个框架必须要等很长时间。规则是:如果一定的框架页面 没有使用Session,就一定要告诉ASP直接使用@EnableSessionState=False。

        除了使用Session对象,还有许多其他管理会话状态的选择。对于小数量的状态(小于4KB),我们通常建议使用cookie、查询字符串变量以及表单隐藏域。对于象购物车一样的大数量数据,后台数据库是最合适的选择。

        如果要编写很多VBScript或者JScript,为了提个性能,可以将代码编写成COM对象并且编译使用。编译代码基本上比解释性代码运行快许多,编译组件对象可通过'early binding'存取其他COM对象,这比在脚本中调用组件要有效。

这么做有许多优点:

      COM对象有益于从商业规则中独立出表达式规则
      COM对象使代码重用变为可能
      许多开发者发现用VB,C++或者Visual J++编写程序,比ASP更容易调试

      COM对象也有缺点,包括初始开发时间和对不同编程技巧的需要。注意将少量ASP代码做成COM对象组件不会有好处,反而可能导致性能的损失,从而失去了 编译代码的优势。怎样组合使用ASP脚本和COM对象达到最佳性能是一个测试的问题。我们注意到微软公司已经大规模在Windows 2000/IIS 5.0上提高了脚本与ADO的性能,由此,随着IIS5.0版本的引进,减少了编译代码的性能优势。

        使用Option Explicit

要在ASP文件中使用Option Explicit定义,并且放置到ASP文件的头部,从而强迫开发者在使用前声明所有的变量。许多程序员都认为这在应用程序调试时非常有用,因为它避免了产生错误类型变量以及偶然创建新变量的可能。

       也许更重要的是,声明的变量要大大快于非声明变量。

       拷贝经常使用的数据到脚本变量中

在ASP中存取COM对象时,应该拷贝经常使用的对象数据到脚本变量中,这样就减少了对COM对象的方法调用。这些调用要比存取脚本变量相对来说费时费力。当存取Collection和Dictionary对象时,使用这项技巧也减少了昂贵的查找操作。

        通常,如果要不止一次地存取对象数据,就应将数据放入脚本变量中,对象数据主要也就是Request变量(表单和查询字符串变量)。比如,站点要传递一个 叫做UserID的查询字符串变量,假设它将在一个特殊页面被引用12次,那么不需要调用Request('UserID')12次,只要在ASP页面的 头部分配给UserID一个变量,然后在页面中使用它,这样做就节省了11次COM方法的调用。

        避免再定义数组

争取不要再定义数组。考虑到性能问题,如果机器的物理内存大小不够,最好按最差情况或者最佳情况设置数组的初始尺寸,需要时再重新定义。

        在任何可能时使用Server.Transfer,而不要用Response.Redirect

Response.Redirect告诉浏览器请求另一个不同的页面,这常常用于引导用户到登录页面或者出错处理页面。由于重定向强迫了一个新页面请 求,结果是浏览器必须要与Web服务器循环2次,并且Web服务器必须处理一个额外的请求。IIS5.0引进了一个新功能 Server.Transfer,它执行在同一服务器上的页面传输,这将避免额外的浏览器-Web服务器的数据循环,形成良好的系统性能,对于用户也有较 好的响应时间。

       避免使用服务器变量

存取服务器变量导致Web站点建立一个特殊的请求并收集所有的服务器变量,而并不是你要求的那个变量。这类似于在文件夹中取回一个特殊的文件,要想取回一个文件,就得首先获取所在文件夹的信息。

不要存取非法的Request对象(比如Request('Data')),对于那些不在Request.Cookies、 Request.Form、Request.QueryString或者Request.ClientCertificate中的项目,隐含就指向了 Request.ServerVariables变量,而这些变量要比其他集合对象慢得多。

调整Web服务器

有几个IIS调整参数可以提高站点性能。比如,对于IIS4.0,我们经常发现提高ASP ProcessorThreadMax参数能够产生重大的效果,特别是在那些要等待后台资源比如数据库或中间件产品的站点。在IIS5.0中,你可以发现 调整ASP线程通道要比调整AspProcessorThreadMax效果更佳。

        最佳的配置设定取决于应用程序代码、支持的硬件设备以及客户端的工作量。发现最佳配置的唯一方法就是测试。

        性能是一个很重要的特征。你需要事先设计好性能指标,否则日后就要为此重新编写程序。就是说:要设想好怎样最佳化地执行ASP程序?

本文提出了一些优化ASP应用和VBScript的技巧,许多技巧和缺陷都经过了研讨。这里列出的建议已经在http://www.microsoft.com 和其他站点上进行了测试,都工作得非常好。本文假设你具备ASP开发的基本知识,包括VBScript或者JScript,ASP应用程序,ASP Session,以及其他ASP内置对象(Request,Response和Server)。

        通常,ASP的执行性能远远不仅仅依赖ASP代码本身!在本文的尾部列出了与性能相关的资源,它们含概了ASP和非ASP的部分,包含ActiveX Data Objects(ADO),Component Object Model(COM),数据库(Database),以及Internet信息服务器(IIS)的配置。除了这些,还有一些非常好的链接值得你一看。

在Web服务器上缓存经常使用的数据

典型的情况是:ASP页面从后台存储中取回数据,然后以超文本标记语言(HTML)的形式形成结果。不管数据库的速度如何,从内存中取回数据要比从后 台存储设备中快得多。从本地硬盘读取数据通常也非常快。所以,提高性能可以通过缓存服务器上的数据来实现,无论是将数据缓存在内存中,或者本地硬盘中。

        缓存是经典的'空间换时间'的折中方式。如果缓存得恰当,就可以看到显著的性能提升。为了让缓存有效,必须保证缓存数据是经常要重用的,而且也是计算起来繁琐的。装满陈旧数据的缓存是对内存的浪费。

不经常改变的数据是缓存的较好对象,因为不需要随时考虑这些数据更新后的同步操作。组合框、参考表格、DHTML代码、扩展标记语言串、菜单以及站点 配置变量(包括数据源名字DSNS,Internet协议地址IP以及Web路径)都是很好的缓存对象。注意:要缓存数据表达式而不是数据本身。如果一个 ASP页面经常变化并且很费力去缓存(比如整个产品目录),就要考虑预产生HTML,而不是每次发生请求时再描述它。

在Application或Session对象中缓存经常使用的数据

ASP中的Application和Session对象是在内存中缓存数据的便利容器。你可以将数据赋值给Application和Session对 象,这些数据在HTTP调用期间将一直保持在内存中。Session中的数据是为每一个用户服务的,Application中的数据是所有用户共享的。

        何时需要在Application和Session中装入数据?通常,当应用程序启动或者会话开始时,数据就被装入了。为了在这时装入数据,在 Application OnStart()或者Session OnStart()中分别添加适当的代码。这些函数位于文件Global.asa中,如果原来不存在,就添加上。也可以在数据首次需要的时候调入,在 ASP页面中添加代码,检查数据是否存在,如果没有发现,就调入它。这里有一个例子,它代表了被称为'lazy evalution'的经典性能处理技术:直到需要时,再去计算。

例子如下:

<%
Function GetEmploymentStatusList
Dim d
d = Application('EmploymentStatusList')
If d = '' Then
' FetchEmploymentStatusList function (not shown)
' fetches data from DB, returns an Array
d = FetchEmploymentStatusList()
Application('EmploymentStatusList') = d
End If
GetEmploymentStatusList = d
End Function
%>


对于不同的数据,可以编写类似的函数代码。

数据应该按什么格式保存?任何变量类型都可以,因为所有的脚本变量都是不同的。比如说,可以保存为字符串、整型或者数据。通常,将ADO记录集的内容存储 到这些变量类型中一个。为了从ADO记录集中取出数据,需要手工地拷贝数据到VBScript变量中,每次一个字段。使用任意一个ADO记录集的函数 functions GetRows(),GetString() 或者 Save() (ADO 2.5)都非常得快速而且简单,这里有个函数,描述了如何使用GetRows()返回记录集数据的数组:

' Get Recordset, return as an Array
Function FetchEmploymentStatusList
Dim rs
Set rs = createObject('ADODB.Recordset')
rs.Open 'select StatusName, StatusID from EmployeeStatus', _
'dsn=employees;uid=sa;pwd=;'
FetchEmploymentStatusList = rs.GetRows() ' Return data as an Array
rs.Close
Set rs = Nothing
End Function


上述代码的一个更深的技巧是为列表缓存了HTML。下面是个简单的例子:

' Get Recordset, return as HTML Option list
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = createObject('ADODB.Recordset')
rs.Open 'select StatusName, StatusID from EmployeeStatus', _
'dsn=employees;uid=sa;pwd=;'
s = '<select name=''EmploymentStatus'>' & vbCrLf
Set fldName = rs.Fields('StatusName') ' ADO Field Binding
Do Until rs.EOF
' Next line violates Don't Do String Concats,
' but it's OK because we are building a cache
s = s & ' <option>' & fldName & '</option>' & vbCrLf
rs.MoveNext
Loop
s = s & '</select>' & vbCrLf
rs.Close
Set rs = Nothing ' See Release Early
FetchEmploymentStatusList = s ' Return data as a String
End Function
在合适的环境下,可以在Application或者Session中缓存ADO记录集本身,但是有2点提示:

        ADO必须是自由线程标记的
        需要使用disconnected recordset方式
如果不能保证上述2个条件,就不要缓存ADO记录集,因为这会产生很大的危险性

相关阅读:
Top