下载 第26章优化ASP的性能 有些性能指标,例如正确性,是只有在其不出现时才被人们注意到的品质特征。如果能 努力地改正网站中的所有错误,并不断提高其工作性能,那么其用户很少会提意见。如果网 站存在少量错误,或者是运行缓慢,那么其用户们会产生抱怨 本章将介绍与ASP工作性能有关的几个重要概念,提供一些优化ASP工作性能的方法和应 注意的事项。 本章的主要内容如下: ·以处理速率和响应时间衡量性能指标, 硬件的性能 ·脚本优化 NT Performance moniter和 Web Application Tool(WAS)等工具。 会话和应用程序状态 进程隔离、组件和线程模型。 最后,我们用一些综合技巧结束本章的内容,这些技巧在实践中行之有效,而且可以用 来改善网站性能。首先,让我们考虑一下应该用什么样的尺度来衡量ASP的工作性能 26.1衡量工作性能的标准 在研究如何提高ASP的工作性能之前,我们需要来理解两个基本的指标:吞吐量和响应 时间 吞吐量( Throughput):是指服务器处理请求的速率。从网络管理员的角度来看,可以实 现的吞吐量越高越好。如果能够提升网站潜在的吞吐量,就可以应付日益增加的用户请求 就能处理更多的事情:而且也可以因此推迟升级服务器的硬件 响应时间( Response Time):是指从客户开始提出请求到接收到响应最后一个比特之间 的时间。响应时间越短越好。用户很在意响应时间,对全系统的吞吐量不太关注 26.1.1吞吐量 吞吐量通常用每秒或每天的请求次数来衡量。有时,使用页请求数比使用请求次数更有 意义。当浏览者要求得到一个HTML页面时,一般会紧跟着发出与图片和网页有关的独立请 求,其中图片一般都标有的标记。这些紧密联系着的请求被视为一个页面请求 另一个近似衡量吞吐量的方法是客户数量除以客户的“思考时间”。例如,假如有100个 客户,平均每人用20秒阅读一个网页,那么吞吐量就是100/20,或者说是每秒回答5次。吞吐 量并非表示阅读一个网页需要的时间,表明请求多快才能到达服务器,服务器要多久才能对 它们做出响应 吞吐量受许多变化因素影响。其中之一就是带宽,带宽是用来计量每秒能够传输多少数 据的物理量。如果使用一条ISDN线来连接到 Internet,那么由于ISDN很容易饱和,相对较低
下载 第26章 优化ASP的性能 有些性能指标，例如正确性，是只有在其不出现时才被人们注意到的品质特征。如果能 努力地改正网站中的所有错误，并不断提高其工作性能，那么其用户很少会提意见。如果网 站存在少量错误，或者是运行缓慢，那么其用户们会产生抱怨。 本章将介绍与A S P工作性能有关的几个重要概念，提供一些优化 A S P工作性能的方法和应 注意的事项。 本章的主要内容如下： • 以处理速率和响应时间衡量性能指标。 • 硬件的性能。 • 脚本优化。 • NT Performance Moniter 和 Web Application To o l（WA S）等工具。 • 会话和应用程序状态。 • 进程隔离、组件和线程模型。 最后，我们用一些综合技巧结束本章的内容，这些技巧在实践中行之有效，而且可以用 来改善网站性能。首先，让我们考虑一下应该用什么样的尺度来衡量 A S P的工作性能。 26.1 衡量工作性能的标准 在研究如何提高 ASP 的工作性能之前，我们需要来理解两个基本的指标：吞吐量和响应 时间。 吞吐量（T h r o u g h p u t）：是指服务器处理请求的速率。从网络管理员的角度来看，可以实 现的吞吐量越高越好。如果能够提升网站潜在的吞吐量，就可以应付日益增加的用户请求； 就能处理更多的事情；而且也可以因此推迟升级服务器的硬件。 响应时间（Response Ti m e）：是指从客户开始提出请求到接收到响应最后一个比特之间 的时间。响应时间越短越好。用户很在意响应时间，对全系统的吞吐量不太关注。 26.1.1 吞吐量 吞吐量通常用每秒或每天的请求次数来衡量。有时，使用页请求数比使用请求次数更有 意义。当浏览者要求得到一个 H T M L页面时，一般会紧跟着发出与图片和网页有关的独立请 求，其中图片一般都标有的标记。这些紧密联系着的请求被视为一个页面请求。 另一个近似衡量吞吐量的方法是客户数量除以客户的“思考时间”。例如，假如有 1 0 0个 客户，平均每人用2 0秒阅读一个网页，那么吞吐量就是 1 0 0 / 2 0，或者说是每秒回答 5次。吞吐 量并非表示阅读一个网页需要的时间，表明请求多快才能到达服务器，服务器要多久才能对 它们做出响应。 吞吐量受许多变化因素影响。其中之一就是带宽，带宽是用来计量每秒能够传输多少数 据的物理量。如果使用一条 I S D N线来连接到I n t e r n e t，那么由于I S D N很容易饱和，相对较低
第6章优化SP的性能783 的带宽将成为限制性能的主要因素。带宽是限制网络服务器向用户快速传递内容的一个主要 网页尺寸( Page size)同样影响吞吐量。传递的网页越大,每页花费的时间越多,每秒 可以传递的网页越少。如果可以减少网页的尺寸(尤其是嵌入式图片的尺寸,这些图片往往 是最大的文件),不仅可以提高吞吐量,而且减少了响应时间:也就是说,客户看到完整一页 所需的时间更少。 复杂的应用程序( Complex application)会降低吞吐量。如果每一个请求都需要花费较长 的时间来执行,那么每秒可以处理的请求数就比处理简单的申请时少。对于动态内容来说, CPU的性能是影响吞吐量的主要因素 在速度较快的局域网上,HTTP的连接是几乎瞬时完成的。但是,在相对较慢的广域网上 例如 IInternet,它的连接就需要几秒钟。同时,由于每一个连接都要使用服务器资源,所以并 发连接个数成了重要的指标。 有两种方法测量吞吐量: 是使用性能监视器( Performance monitor)来读取由网络服务器产生的吞吐量统计数据 对于静态文件来说,NT性能计数器为 Web Service(Tota)| Get Requests/sec;对于ASP来说, NT性能计数器为 Actire Server Pages Requests/sec。本章的后面将详细讨论性能计数器 是使用装载产生工具,例如WAS。在运行了一个特殊的测试程序后,WAS将报告吞吐 量和许多其他的统计数据。 26.1.2响应时间 用户希望响应时间少于一秒,但是却很少能够实现。人们经常半开玩笑地称WWW是 “世界范围内的等待( World- Wide wait)”。响应时间取决于网络延时、请求在服务器端排队 的时间及服务器处理请求的时间 WAS提供获得第一个比特的时间(TIFB)和获得最后一个比特的时间(TTLB) 的统计纪录。 网络延时是一个数据包从一个地方传送到另一个地方的时间,它受以下几个因素的影响 网络拥挤度、链路的质量、链路的带宽、链节点间的物理距离,与目的地之间的中继站或区 域的个数和在路由器和网关的等待时间 延时既受到请求从客户端传递到服务器端的时间的影响,也受到从服务器端到客户端返 回响应的时间的影响。在大多数情况下,响应时间既不受客户控制也不受服务器控制。 窄带设备,例如调制解调器,延时更长。相反,宽带设备通常延时较少,不过并非总是 如此。两个通过微波、卫星连接的系统,每秒可以传递几百万比特的数据,但如果仅把单个 数据从一个终端经卫星传送到另一个终端的话,花费的时间比在局域网内传输要长 即使从客户端到服务器的延时为零,任何一个请求在排队等待接受服务器处理时仍要花 费时间。请求排队时间取决于队列的长度和服务器处理每个请求的时间。队列的长度与服务 器的负荷成比例。 请求执行时间是响应时间的最后一个组成部分。它是唯一的一个服务器可以控制的量。 较长的处理时间会减低吞吐量。减少执行时间是本章的主要任务。 业务量特性曲线
第26章 优化ASP 的性能计计783 下载 的带宽将成为限制性能的主要因素。带宽是限制网络服务器向用户快速传递内容的一个主要 因素。 网页尺寸（Page size）同样影响吞吐量。传递的网页越大，每页花费的时间越多，每秒 可以传递的网页越少。如果可以减少网页的尺寸（尤其是嵌入式图片的尺寸，这些图片往往 是最大的文件），不仅可以提高吞吐量，而且减少了响应时间；也就是说，客户看到完整一页 所需的时间更少。 复杂的应用程序（Complex application）会降低吞吐量。如果每一个请求都需要花费较长 的时间来执行，那么每秒可以处理的请求数就比处理简单的申请时少。对于动态内容来说， C P U的性能是影响吞吐量的主要因素。 在速度较快的局域网上，H T T P的连接是几乎瞬时完成的。但是，在相对较慢的广域网上， 例如I n t e r n e t，它的连接就需要几秒钟。同时，由于每一个连接都要使用服务器资源，所以并 发连接个数成了重要的指标。 有两种方法测量吞吐量： 一是使用性能监视器（Performance Monitor）来读取由网络服务器产生的吞吐量统计数据。 对于静态文件来说，N T性能计数器为Web Service (_Total) | Get Raquests/sec；对于A S P来说， N T性能计数器为 Actire Server Pages | Requests/sec。本章的后面将详细讨论性能计数器。 二是使用装载产生工具，例如 WA S。在运行了一个特殊的测试程序后， WA S将报告吞吐 量和许多其他的统计数据。 26.1.2 响应时间 用户希望响应时间少于一秒，但是却很少能够实现。人们经常半开玩笑地称 W W W是 “世界范围内的等待（ Wo r l d - Wide Wa i t）”。响应时间取决于网络延时、请求在服务器端排队 的时间及服务器处理请求的时间。 WAS 提供获得第一个比特的时间（ T T F B）和获得最后一个比特的时间（ T T L B） 的统计纪录。 网络延时是一个数据包从一个地方传送到另一个地方的时间，它受以下几个因素的影响： 网络拥挤度、链路的质量、链路的带宽、链节点间的物理距离，与目的地之间的中继站或区 域的个数和在路由器和网关的等待时间。 延时既受到请求从客户端传递到服务器端的时间的影响，也受到从服务器端到客户端返 回响应的时间的影响。在大多数情况下，响应时间既不受客户控制也不受服务器控制。 窄带设备，例如调制解调器，延时更长。相反，宽带设备通常延时较少，不过并非总是 如此。两个通过微波、卫星连接的系统，每秒可以传递几百万比特的数据，但如果仅把单个 数据从一个终端经卫星传送到另一个终端的话，花费的时间比在局域网内传输要长。 即使从客户端到服务器的延时为零，任何一个请求在排队等待接受服务器处理时仍要花 费时间。请求排队时间取决于队列的长度和服务器处理每个请求的时间。队列的长度与服务 器的负荷成比例。 请求执行时间是响应时间的最后一个组成部分。它是唯一的一个服务器可以控制的量。 较长的处理时间会减低吞吐量。减少执行时间是本章的主要任务。 业务量特性曲线
78493;高级程 Chinapub coM 下载 另一个概念是业务量特性曲线,业务量曲线在一天内并不平坦。地区性的新闻网站在清 晨、午饭时间和傍晚会有较重的业务量,但在半夜却非常闲,这时其主要读者已经睡着了 在业务较重的时间,服务器可能要处理三到五倍于24小时平均业务量的业务。新闻网站在发 生突发新闻事件时会偶尔遇到尖峰业务量 显然,一个Web站点必须不仅可以处理平均业务量,也必须有足够能力应付 天中可能的高峰,而且它的速率最好能应付得了最高容量。 从长远角度看,应该建成一个可以适应日益增长的业务量的成功网站。不要让服务器超 负荷运转。如果平均业务量占用了CPU资源的50%,那就可能不能很好地应付业务量的高峰 使用 NT Performance monitor来了解站点的工作情况。 Hermon可以把所有计数值记录到一个 日志并在NT事件日志中报警。 26.1.3衡量性能的其他指标 如前所述,衡量工作性能最基本的标准是吞吐量(服务器每秒可以处理的请求数量)和 响应时间(处理一个指定的请求有多快)。作为一个网络管理员或者ASP应用程序开发者,最 关心的是使吞吐量最大,因为它既能够使网站可以处理更多的下载请求,还可以推迟升级硬 件。与此不同,用户希望响应时间越短越好,因为他们已经厌倦了“世界范围内的等待 其他的性能指标也是非常有用的。这些指标是兆赫费用、资源利用率和多处理器可扩展 性。兆赫费用是一种估计执行一个动态网页有多“贵”的方法,而且它还能帮助你推断出通 过改换不同的硬件可以得到的性能。使用的资源越少,可用空间就越大,而且对多用途的服 务器来说,就越是好成员。在单处理器系统上开发的应用程序在多处理器系统中并不能自动 地扩展 1.兆赫费用 兆赫费用使用每秒每个请求的兆赫值表示,即:兆赫费用=CPU数量×CPU速度×CPU利 用率/每秒请求数。例如,如果一个双奔腾Ⅱ服务器的工作频率为333MHz,系统可以利用60% 的CPU资源稳定地工作在80页/秒的速度上(由 Task Manager或 Performance moniter实测得到), 即 总频率为2×333MHz=666MHz,可利用的频率为:666×0.60=400MHz,因此,400 MHz/80页/秒=5(MHz/每秒页),所以,兆赫费用为5MHz/每秒页 兆赫费用与吞吐量等其他指标相比有一定的优点,它使得规划系统的容量变得相对容易。 例如,尽管系统B与系统A的硬件不同,假如两个系统的CPU个数相同,并且一个页面的兆赫 费用一定的话,则页面在系统A与在系统B运行的兆赫费用基本相同,只是在速度较快的机器 会略高一点 然而现在还不能把兆赫费用看得太重:它仅仅是一个估计值。对动态内容的处 理能力还无法确定。 例如,网站上最高层的主页的兆赫费用为3,搜索网页是25,订单网页是15。网站可承受 的速率是每秒有50个客户访问最高层的主页,一人在搜索,2人在下订单,同时还需有一些剩 余能力用来对付业务高峰和满足其他网页的用户的要求。网站的兆赫费用多大才能满足需
另一个概念是业务量特性曲线，业务量曲线在一天内并不平坦。地区性的新闻网站在清 晨、午饭时间和傍晚会有较重的业务量，但在半夜却非常闲，这时其主要读者已经睡着了。 在业务较重的时间，服务器可能要处理三到五倍于 2 4小时平均业务量的业务。新闻网站在发 生突发新闻事件时会偶尔遇到尖峰业务量。 显然，一个 We b站点必须不仅可以处理平均业务量，也必须有足够能力应付一 天中可能的高峰，而且它的速率最好能应付得了最高容量。 从长远角度看，应该建成一个可以适应日益增长的业务量的成功网站。不要让服务器超 负荷运转。如果平均业务量占用了 C P U资源的5 0 %，那就可能不能很好地应付业务量的高峰。 使用NT Performance Monitor来了解站点的工作情况。 PerMon 可以把所有计数值记录到一个 日志并在NT 事件日志中报警。 26.1.3 衡量性能的其他指标 如前所述，衡量工作性能最基本的标准是吞吐量（服务器每秒可以处理的请求数量）和 响应时间（处理一个指定的请求有多快）。作为一个网络管理员或者 A S P应用程序开发者，最 关心的是使吞吐量最大，因为它既能够使网站可以处理更多的下载请求，还可以推迟升级硬 件。与此不同，用户希望响应时间越短越好，因为他们已经厌倦了“世界范围内的等待”。 其他的性能指标也是非常有用的。这些指标是兆赫费用、资源利用率和多处理器可扩展 性。兆赫费用是一种估计执行一个动态网页有多“贵”的方法，而且它还能帮助你推断出通 过改换不同的硬件可以得到的性能。使用的资源越少，可用空间就越大，而且对多用途的服 务器来说，就越是好成员。在单处理器系统上开发的应用程序在多处理器系统中并不能自动 地扩展。 1. 兆赫费用 兆赫费用使用每秒每个请求的兆赫值表示，即：兆赫费用 = CPU数量×C P U速度×C P U利 用率/每秒请求数。例如，如果一个双奔腾 I I服务器的工作频率为3 3 3 M H z，系统可以利用6 0 % 的C P U资源稳定地工作在8 0页/秒的速度上（由Task Manager 或Performance Moniter实测得到）， 即： 总频率为2×333 MHz = 666 MHz，可利用的频率为：6 6 6×0.60 = 400 MHz，因此，4 0 0 MHz / 80页/ 秒 = 5 （M H z /每秒页），所以，兆赫费用为5 MHz/每秒页。 兆赫费用与吞吐量等其他指标相比有一定的优点，它使得规划系统的容量变得相对容易。 例如，尽管系统B与系统A的硬件不同，假如两个系统的 C P U个数相同，并且一个页面的兆赫 费用一定的话，则页面在系统 A与在系统B运行的兆赫费用基本相同，只是在速度较快的机器 会略高一点。 然而现在还不能把兆赫费用看得太重；它仅仅是一个估计值。对动态内容的处 理能力还无法确定。 例如，网站上最高层的主页的兆赫费用为 3，搜索网页是2 5，订单网页是1 5。网站可承受 的速率是每秒有5 0个客户访问最高层的主页，一人在搜索， 2人在下订单，同时还需有一些剩 余能力用来对付业务高峰和满足其他网页的用户的要求。网站的兆赫费用多大才能满足需 求？ 784计计ASP 3 高级编程 下载
第6章优化SP的性能785 (50×3)+(2×15)+(1×25)=150+30+25=205MHz 考虑到系统业务高峰时的冗余,至少要使系统的兆赫容量达到300MHz,才可以满足需求 建议系统的平均工作量不超过CPU资源的50%,否则将不能很好地应付业务」 的高峰。 这个网站的工作频率为400MHz是比较安全的。 2.降低CPU的占用率 很明显,CPU占用率越低越好。如果可以优化网页使其可以运行得更快且占用最少的 CPU资源,那么网站就有更多的能力来应付业务高峰。另外,对于运行在同一系统上的数据 库和电子邮件服务器等其他服务来说,希望让给它们尽可能多的CPU资源 3.降低带宽的占用率 即使是专用的网络服务器也不得不与其他系统分享网络资源。因此,应该尽可能地占用 较少的网络带宽资源。这不仅仅意味着可以给其他系统留下更多的带宽,还可以使网络服务 器达到更高的吞吐量和提供更短的客户响应时间。有三种方法可以实现这一目标 ·第一种方法是为每个请求传递较少的数据。去掉HTML文件中的空格:发送一部分结果 以代替整个结果:发送尽可能少的图片,并且通过剪切使图片尽可能小,或使用较高压 缩比例的JPEG和颜色较少的GIF方式使图片变小 第二种方法是减少客户与服务器在网络上的往返时间。服务器可以下载给客户的信息越 多越好。往返时间经常由于网络的等待时间而变长,并由此增加了服务器的工作量,还 占用了网络的带宽资源。优秀的客户可以用客户端脚本来验证数据;使用 DHTML来改 变显示器的显示图案而不用请求从服务器下载新的HTML文件或图片:;用RDS来巧妙地 处理ADO记录集;用XML来转换数据等 ·第三种方法是数据缓冲。把数据寄存起来,然后一次性发出可以节约网络资源的占用 IS40的缺省值并不缓冲ASP动态网页,而IS50的缺省值是缓冲ASP动态网页 每一个 Response. Write和HIML段分别传递给客户的。每个数据包内都加上了描述性的报 头:每一次传递都需要花时间来完成:每一次传递都给网络増添了阻塞问题。这就像分几次 从超级市场买回采购单上的物品而不是一次把所有的东西都买回来一样。TCPP协议有一种 慢开始的算法,它先传递一个数据包,然后是一次两个,再一次传递四个,如此下去,直到 建立起最大的数据传输速率为止。如果一个网页被分割成许多小的部分来传送,TCP/IP对每 次传递都有一个慢开头的数据流,而不是对整个数据仅用一个慢开头的数据流。当整个网页 被缓冲后,TCP/P会变得更高效,尤其是在等待时间较长的连接上 4.多处理器的可扩展性 理想情况下,在单处理器系统中增加一个处理器可以使吞吐量加倍,再加两个处理器可 以得到四倍的处理性能。但是,实际中一个应用程序很难在多处理器系统上扩展。IIS4.0可 以很好地出从一个处理器扩展到两个处理器,但超过两个就不行了。IS5.0可以扩展到出4个 甚至是8个处理器 图26-1表示了在IS5.0中ASP的性能改善情况。它表明了一个经常使用 Lookup Table组件 的不太复杂的ASP脚本(大约1000行的代码,产生约25KB的HTML文件)在IS50中的性能 改善情况
第26章 优化ASP 的性能计计785 下载 （5 0×3）+（2×1 5）+（1×2 5）= 150 + 30 + 25 = 205 MHz 考虑到系统业务高峰时的冗余，至少要使系统的兆赫容量达到 3 0 0 M H z，才可以满足需求 了。 建议系统的平均工作量不超过 C P U资源的5 0 %，否则将不能很好地应付业务量 的高峰。 这个网站的工作频率为4 0 0 M H z是比较安全的。 2. 降低C P U的占用率 很明显， C P U占用率越低越好。如果可以优化网页使其可以运行得更快且占用最少的 C P U资源，那么网站就有更多的能力来应付业务高峰。另外，对于运行在同一系统上的数据 库和电子邮件服务器等其他服务来说，希望让给它们尽可能多的 C P U资源。 3. 降低带宽的占用率 即使是专用的网络服务器也不得不与其他系统分享网络资源。因此，应该尽可能地占用 较少的网络带宽资源。这不仅仅意味着可以给其他系统留下更多的带宽，还可以使网络服务 器达到更高的吞吐量和提供更短的客户响应时间。有三种方法可以实现这一目标： • 第一种方法是为每个请求传递较少的数据。去掉 H T M L文件中的空格；发送一部分结果 以代替整个结果；发送尽可能少的图片，并且通过剪切使图片尽可能小，或使用较高压 缩比例的J P E G和颜色较少的G I F方式使图片变小。 • 第二种方法是减少客户与服务器在网络上的往返时间。服务器可以下载给客户的信息越 多越好。往返时间经常由于网络的等待时间而变长，并由此增加了服务器的工作量，还 占用了网络的带宽资源。优秀的客户可以用客户端脚本来验证数据；使用 D H T M L来改 变显示器的显示图案而不用请求从服务器下载新的 H T M L文件或图片；用R D S来巧妙地 处理A D O记录集；用X M L来转换数据等。 • 第三种方法是数据缓冲。把数据寄存起来，然后一次性发出可以节约网络资源的占用。 IIS 4.0的缺省值并不缓冲A S P动态网页，而IIS 5.0的缺省值是缓冲A S P动态网页。 每一个R e s p o n s e . Wr i t e和H T M L段分别传递给客户的。每个数据包内都加上了描述性的报 头；每一次传递都需要花时间来完成；每一次传递都给网络增添了阻塞问题。这就像分几次 从超级市场买回采购单上的物品而不是一次把所有的东西都买回来一样。 T C P / I P协议有一种 慢开始的算法，它先传递一个数据包，然后是一次两个，再一次传递四个，如此下去，直到 建立起最大的数据传输速率为止。如果一个网页被分割成许多小的部分来传送， T C P / I P对每 次传递都有一个慢开头的数据流，而不是对整个数据仅用一个慢开头的数据流。当整个网页 被缓冲后，T C P / I P会变得更高效，尤其是在等待时间较长的连接上。 4. 多处理器的可扩展性 理想情况下，在单处理器系统中增加一个处理器可以使吞吐量加倍，再加两个处理器可 以得到四倍的处理性能。但是，实际中一个应用程序很难在多处理器系统上扩展。 IIS 4.0可 以很好地出从一个处理器扩展到两个处理器，但超过两个就不行了。 IIS 5.0可以扩展到出4个 甚至是8个处理器。 图2 6 - 1表示了在IIS 5.0中A S P的性能改善情况。它表明了一个经常使用 L o o k u p Ta b l e组件 的不太复杂的A S P脚本（大约1 0 0 0行的代码，产生约25 KB的H T M L文件）在IIS 5.0中的性能 改善情况
786s3高级程 下载 IS5中的ASP性能提高 2P 口4P Nt4 sp5 NT4 sp5+W2K,Beta3 VBS 图26-1S5.0中ASP的性能改善情况 应用程序无法很好地扩展的原因是资源争用和串行化过程。每一个线程都在争用共享的 资源、组件的关键部分或系统总线。当一个线程对某一资源进行独占访问时,其他线程被阻 塞,只有第一个线程释放这些资源,其他线程才能再使用这些资源。资源的使用是串行的而 不是并行的。由于单处理器系统在一个瞬间实际只有执行一个线程,所以这种问题不容易出 现。对有n个处理器的系统,同时执行n个线程,就会出现资源争用问题 如果ASP应用程序要在多处理器系统上使用,首先必须对应用程序在多处理器 系统上的可扩展性和性能进行测试。 通过测试可以把一些诸如线程安全、死锁等问题及发现的其他问题从应用程序中清除掉 26.2改善服务器的硬件性能 必须有合适的硬件支持,才可以满足现在的要求和将来可能的负荷要求。一个奔腾133也 许足以应付小部门的网络服务要求,但却不能满足一个繁忙的商业站点的要求。 262.1内存 服务器有足够的物理内存是至关重要的。如果没有足够的物理内存,那么,改善服务器 性能的最简单最有效的方法就是增加内存。虚拟内存子系统虽能很好地工作,但是系统的吞 吐量将会大大降低,因为系统将很多的时间用在内存与硬盘之间的页面交换上。即使系统有 足够的内存,增加内存仍能提高系统性能。IS的核心需要大量内存来高速缓存存储静态文件, ASP需要内存来存储编译了的ASP文件和ASP会话数据。 可以使用 NT Performance Monitor来诊断内存问题。在 IS Technet网站和MSDN 网络服务器技术站点上,有些文章对这一问题做了进一步的讨论,微软出版社出版的 《 IIS Resource uide》对这一问题也进行了研究 128MB是专用网络服务器的最小内存数,增加到256MB较好,如果是任务比较繁重的商 业网站,内存应为512MB到1GB。增加内存可以改善服务器的工作性能,最终将逐渐接近系 统的最高性能,例如,少数服务器的实际内存为2GB
图26-1 IIS 5.0中A S P的性能改善情况 应用程序无法很好地扩展的原因是资源争用和串行化过程。每一个线程都在争用共享的 资源、组件的关键部分或系统总线。当一个线程对某一资源进行独占访问时，其他线程被阻 塞，只有第一个线程释放这些资源，其他线程才能再使用这些资源。资源的使用是串行的而 不是并行的。由于单处理器系统在一个瞬间实际只有执行一个线程，所以这种问题不容易出 现。对有n个处理器的系统，同时执行 n个线程，就会出现资源争用问题。 如果A S P应用程序要在多处理器系统上使用，首先必须对应用程序在多处理器 系统上的可扩展性和性能进行测试。 通过测试可以把一些诸如线程安全、死锁等问题及发现的其他问题从应用程序中清除掉。 26.2 改善服务器的硬件性能 必须有合适的硬件支持，才可以满足现在的要求和将来可能的负荷要求。一个奔腾 1 3 3也 许足以应付小部门的网络服务要求，但却不能满足一个繁忙的商业站点的要求。 26.2.1 内存 服务器有足够的物理内存是至关重要的。如果没有足够的物理内存，那么，改善服务器 性能的最简单最有效的方法就是增加内存。虚拟内存子系统虽能很好地工作，但是系统的吞 吐量将会大大降低，因为系统将很多的时间用在内存与硬盘之间的页面交换上。即使系统有 足够的内存，增加内存仍能提高系统性能。 I I S的核心需要大量内存来高速缓存存储静态文件， A S P需要内存来存储编译了的A S P文件和A S P会话数据。 可以使用N T Performance Monitor来诊断内存问题。在IIS Technet 网站和 M S D N 网络服务器技术站点上，有些文章对这一问题做了进一步的讨论 ,微软出版社出版的 《IIS Resource Guide》对这一问题也进行了研究。 1 2 8 M B是专用网络服务器的最小内存数，增加到 2 5 6 M B较好，如果是任务比较繁重的商 业网站，内存应为 5 1 2 M B到1 G B。增加内存可以改善服务器的工作性能，最终将逐渐接近系 统的最高性能，例如，少数服务器的实际内存为 2 G B。 786计计ASP 3 高级编程 下载 IIS 5 中的ASP 性能提高 进程 内 进程 外 进程 内 进程 外 进程 内 进程 外
第6章优化sP的性787 26.2.2硬盘 硬盘用来存储静态的内容(HTML文件和图片)、程序、脚本、日志文件和数据库等。对 许多的网站来说,标准的IDE或SCSI硬盘就够用了。将系统文件、数据库、日志文件、临时 文件和网页文件分别存储到不同的物理硬盘上,可以减少硬盘磁头的寻找时间,从而改善性 能。硬盘工作量较多的网站应该使用RAID0、RAID1或RAID5硬盘子系统来提高硬盘的吞 吐量。一定要确定硬盘的工作瓶颈不是由过度页面交换所致。 26.2.3网络带宽 确保有足够的网络带宽可以满足网络服务器的负荷要求,确保有合适的网卡和网络交换 器。快速的以太网(100Mbps)在大多数情况下能满足需要,主要的问题是费用太高 26.2.4cPU 用IS传递静态文件非常高效,但是要产生一个动态文件就要占用许多CPU资源。如果服 务器经常满负荷使用CPU,那就应考虑换一个速度更快的CPU了。如果已经有了一个较快的 CPU,那就要考虑增加第二个。如果使用S50,就可以考虑增加到4至8个CPU。 还要确定CPU有较大的二级缓存,每个至少1MB。CPU的二级缓存要比内存快得多。如 果缺乏二级缓存,将影响系统的性能。 26.2.5更多的服务器 有时,一台机器是不够的。它可能应付不了现有工作量。拥有更多的机器可以得到更高 的可用性,即使有一台机器坏了,网站仍能继续正常运行:也就是就没有单一故障点 可以有几种选择。如果web服务器上正在运行一个数据库,可以把数据库转移到后端服 务器上,这样可以减轻服务器的负荷。特别是对于一个Web阵(许多机器作为一台逻辑网络 服务器使用),多服务器更是非常必要的。我们将在下一章详细介绍Web阵。 26.3性能的调整 总体来说,静态内容很少会有性能问题。性能问题常常是由于服务器的硬件不足(尤其 是缺少内存)、带宽不够或网络等待时间长而产生的。然而,IS和其他现代的网络服务器都 擅长传递高容量的静态文件 许多性能问题发生在动态内容上。但不幸的是,这些问题是无法确定的,比较难解决 有无限种方法可以用来编写ASP网页,可它们中的许多是低效的。即使是在像ASP或ISAP这 样完善的系统中,应用程序开发者仍可能写出低效率的代码 26.3.1解决性能问题 首先,必须设置一些合理的目标。例如,指定网站应有能力每秒传递至少50个ASP网页, 且只使用不超过40%的CPU资源,在低于平均负荷时,95%的请求的响应时间低于5秒。然后 最大负荷(或可能的峰值负荷)和平均负荷来衡量网站的工作性能。 最大负荷是指使用WAS等工具在服务器上产生的极高负荷,它使服务器的CPU
26.2.2 硬盘 硬盘用来存储静态的内容（ H T M L文件和图片）、程序、脚本、日志文件和数据库等。对 许多的网站来说，标准的 E I D E或S C S I硬盘就够用了。将系统文件、数据库、日志文件、临时 文件和网页文件分别存储到不同的物理硬盘上，可以减少硬盘磁头的寻找时间，从而改善性 能。硬盘工作量较多的网站应该使用 RAID 0、RAID 1或RAID 5 硬盘子系统来提高硬盘的吞 吐量。一定要确定硬盘的工作瓶颈不是由过度页面交换所致。 26.2.3 网络带宽 确保有足够的网络带宽可以满足网络服务器的负荷要求，确保有合适的网卡和网络交换 器。快速的以太网（1 0 0 M b p s）在大多数情况下能满足需要，主要的问题是费用太高。 26.2.4 CPU 用I I S传递静态文件非常高效，但是要产生一个动态文件就要占用许多 C P U资源。如果服 务器经常满负荷使用 C P U，那就应考虑换一个速度更快的 C P U了。如果已经有了一个较快的 C P U，那就要考虑增加第二个。如果使用 IIS 5.0，就可以考虑增加到4至8个C P U。 还要确定C P U有较大的二级缓存，每个至少 1 M B。C P U的二级缓存要比内存快得多。如 果缺乏二级缓存，将影响系统的性能。 26.2.5 更多的服务器 有时，一台机器是不够的。它可能应付不了现有工作量。拥有更多的机器可以得到更高 的可用性，即使有一台机器坏了，网站仍能继续正常运行；也就是就没有单一故障点。 可以有几种选择。如果 We b服务器上正在运行一个数据库，可以把数据库转移到后端服 务器上，这样可以减轻服务器的负荷。特别是对于一个 We b阵（许多机器作为一台逻辑网络 服务器使用），多服务器更是非常必要的。我们将在下一章详细介绍 We b阵。 26.3 性能的调整 总体来说，静态内容很少会有性能问题。性能问题常常是由于服务器的硬件不足（尤其 是缺少内存）、带宽不够或网络等待时间长而产生的。然而， I I S和其他现代的网络服务器都 擅长传递高容量的静态文件。 许多性能问题发生在动态内容上。但不幸的是，这些问题是无法确定的，比较难解决。 有无限种方法可以用来编写 A S P网页，可它们中的许多是低效的。即使是在像 A S P或I S A P I这 样完善的系统中，应用程序开发者仍可能写出低效率的代码。 26.3.1 解决性能问题 首先，必须设置一些合理的目标。例如，指定网站应有能力每秒传递至少 5 0个A S P网页， 且只使用不超过4 0 %的C P U资源，在低于平均负荷时， 9 5 %的请求的响应时间低于5秒。然后， 用最大负荷（或可能的峰值负荷）和平均负荷来衡量网站的工作性能。 最大负荷是指使用 WA S等工具在服务器上产生的极高负荷，它使服务器的 C P U 第26章 优化ASP 的性能计计787 下载
788sp3高级程 下载 或网络饱和 给出可持续的服务器吞吐量的上限,用平均负荷来测试网站性能看是否达到这一目标 平均负荷量应该根据原始数据或猜测值来模拟。在可能的峰值负荷下测量网站的工作性能可 以检测机器在最繁忙的情况下工作得如何。 如果网站性能达不到要求,就需要找出影响性能的最主要问题,然后解决它。在找到和 解决了这个问题后,应该重新进行测量,重新调整,直到获得了满意的性能或从机器中榨取 出最后一点性能为止。如果还不满意,还可以选择: 增加新硬件 ·重新现实地确定性能指标, 把ASP应用程序的关键部分重写成COM组件或一个 ISAPI 26.3.2强度工具 调节工作性能的关键因素是要知道应用程序的工作。为分析工作,建立一个受控环境是 非常重要的,因为这样可以得到有关负荷能力的正确数据。为了模拟几百个并发客户的行为, 使用多台客户计算机是很必要的。测试应在不受一般的网络活动和尖峰信号干扰的独立网络 中进行,这样得到的结果才是有用的 受控制的强度测试环境的另一个组成部分是网络服务器。强度试验环境要在测试期间提 供一致的不受其他活动影响的环境。这就允许通过改变设置和脚本,来清楚地看到这些变化 的效果。换句话说,当进行性能分析和调节的时候,需要能够提供一系列一致的试验环境 如果试验服务器兼任域控制器或邮件服务器,则试验结果将会因为调用的机器用于其他目的 而改变 理想的情况是由拥有一个测试实验室,其硬件环境与站点相同。然而,这不是必需的 最重要的是这个测试实验室只用于测试期间的测试过程。 旦建立了强度测试实验室,可以选择多种强度工具。有多种选择,价格可以从免费的 到非常昂贵的,功能上从支持HTTP1.0规范到支持Httpi.1规范并有分析和报告的能力。如 果喜欢 Web Application Stress(WAS)工具,可以免费从微软公司得到的,运行界面如图26-2 所示。 则创P。x则對 Sampl[PRepar[ Usen FTCilen 图26-2运行WAS的界面
或网络饱和。 给出可持续的服务器吞吐量的上限，用平均负荷来测试网站性能看是否达到这一目标。 平均负荷量应该根据原始数据或猜测值来模拟。在可能的峰值负荷下测量网站的工作性能可 以检测机器在最繁忙的情况下工作得如何。 如果网站性能达不到要求，就需要找出影响性能的最主要问题，然后解决它。在找到和 解决了这个问题后，应该重新进行测量，重新调整，直到获得了满意的性能或从机器中榨取 出最后一点性能为止。如果还不满意，还可以选择： • 增加新硬件。 • 重新现实地确定性能指标。 • 把A S P应用程序的关键部分重写成 C O M组件或一个I S A P I。 26.3.2 强度工具 调节工作性能的关键因素是要知道应用程序的工作。为分析工作，建立一个受控环境是 非常重要的，因为这样可以得到有关负荷能力的正确数据。为了模拟几百个并发客户的行为， 使用多台客户计算机是很必要的。测试应在不受一般的网络活动和尖峰信号干扰的独立网络 中进行，这样得到的结果才是有用的。 受控制的强度测试环境的另一个组成部分是网络服务器。强度试验环境要在测试期间提 供一致的不受其他活动影响的环境。这就允许通过改变设置和脚本，来清楚地看到这些变化 的效果。换句话说，当进行性能分析和调节的时候，需要能够提供一系列一致的试验环境。 如果试验服务器兼任域控制器或邮件服务器，则试验结果将会因为调用的机器用于其他目的 而改变。 理想的情况是由拥有一个测试实验室，其硬件环境与站点相同。然而，这不是必需的。 最重要的是这个测试实验室只用于测试期间的测试过程。 一旦建立了强度测试实验室，可以选择多种强度工具。有多种选择，价格可以从免费的 到非常昂贵的，功能上从支持 HTTP 1.0规范到支持H T T P 1 . 1规范并有分析和报告的能力。如 果喜欢Web Application Stress（WA S）工具，可以免费从微软公司得到的，运行界面如图 2 6 - 2 所示。 图26-2 运行WA S的界面 788计计ASP 3 高级编程 下载
inapup.com 第6章优化sP的性能789 WAS可以从http://webtool.rtemicrosoft.com下载得到。该站点还提供了有关这个强度工 具的基础知识和综合指南。这个工具包括联机帮助,帮助非常完整,包含许多实例。 263.3脚本优化 有个比喻:一根链条的强度就是其中最脆弱的那个环节的强度。这个比喻同样适用于评 价网络应用程序的性能。可能有几个脚本程序比其他脚本程序慢。然而,网络的性能正是由 于这几个脚本程序的存在变得极差。由于这几个脚本程序占用了可被其他脚本利用的资源 应用程序的性能一般情况下会有所降低。增加环境切换会影响整个应用程序的性能。但如何 查明出现瓶颈的原因呢?毕竟,一个脚本程序有一些包含文件,还有相当数量的代码。我们 希望能够査明脚本的什么地方占用了时间,什么消耗了太多的处理器资源。我常用的方法如 首先,运行强度工具来这个脚本程序以得到性能数据。假设有一个名为 Process Request. aspl的脚本程序,当强度工具运行时,将得到每秒10个请求。这是一个开始点,作为 参考。其次,在脚本程序的“中点”设置一个 Response.End,并且重新运行强度工具。例如 如果 ProcessRequest. asp有100行,那就可以简单地在第50行插入 Response.End。结果如何?脚 本程序的后一半将不会被执行。通过观察前一半的工作性能,可以知道瓶颈是在前一半,还 是在后一半,或者是平均分布在两部分之中。假设没有了后一半脚本程序,得到每秒100个请 求而不是10个,现在就知道了是后一半的某些东西降低了速度。如果得到的结果与“开始点” 接近,说明第一部分有些问题。 现在,移动 Response.End到可能出故障的那一半脚本程序的中点,然后重新运行强度工 具。我们尽力识别产生最大影响的数据库调用和脚本程序。在我们的例子中,在有100行的脚 本程序的第50行处中止它。看到每秒请求从10增加到了100。所以,下一步把 Response.End放 置在第75行然后重新测试。如果工作性能又降回去,可以下结论:问题出现在第50行和第75 行之间。因此,可以 Response.End插在这两点之间,即插在第62行,并重新测试。通过这种 方法,可以查出到底是哪里降低了脚本程序的速度。 如果脚本程序代码的测试数据是线性的又会怎样呢?完全有可能在进行这种测试后,没 有找到特殊问题。在这种情况下,需要确定正在做的事是不是计算量太大了。也许,一些需 要解释的脚本代码应该被调用COM对象所取代,因为这样执行起来较快,参见26.3.10节。 26.34会话和应用程序状态 ASP通过较小的框架提供了许多方便,如 ISAPI。对应用程序和会话状态的透明支持是 ASP值得注意的一个特征。HTTP是一种无状态的协议,所以状态可以被任何用户的两个不同 请求共享。这使HTTP非常可扩展,因为客户和服务器的一次连接不会持续几分钟或几小时。 为了保持会话状态,ASP在每一个响应的报头加上一个 ASPSESSIONID cookie,在客户随后 的请求中,报头都会包含这个 ASPSESSIONID Cookie,ASP就可以利用这个标志,在会话状 态数据库中进行查找。会话状态对于在网上采购应用程序尤其有用。一个来到在线商店的顾 客在采购筐中加入项目。当他决定购买时,ASP就为他们清点商品数目,计算价格。 不幸的是会话状态有一些问题。在我们研究它的缺点之前,让我们来看看它的优点 ·使用起来简单、方便
WA S可以从http: //webtool.rte.microsoft.com下载得到。该站点还提供了有关这个强度工 具的基础知识和综合指南。这个工具包括联机帮助，帮助非常完整，包含许多实例。 26.3.3 脚本优化 有个比喻：一根链条的强度就是其中最脆弱的那个环节的强度。这个比喻同样适用于评 价网络应用程序的性能。可能有几个脚本程序比其他脚本程序慢。然而，网络的性能正是由 于这几个脚本程序的存在变得极差。由于这几个脚本程序占用了可被其他脚本利用的资源， 应用程序的性能一般情况下会有所降低。增加环境切换会影响整个应用程序的性能。但如何 查明出现瓶颈的原因呢？毕竟，一个脚本程序有一些包含文件，还有相当数量的代码。我们 希望能够查明脚本的什么地方占用了时间，什么消耗了太多的处理器资源。我常用的方法如 下： 首先，运行强度工具来这个脚本程序以得到性能数据。假设有一个名为 P r o c e s s R e q u e s t . a s p的脚本程序，当强度工具运行时，将得到每秒 1 0个请求。这是一个开始点，作为 参考。其次，在脚本程序的“中点”设置一个 R e s p o n s e . E n d，并且重新运行强度工具。例如， 如果P r o c e s s R e q u e s t . a s p有1 0 0行，那就可以简单地在第 5 0行插入R e s p o n s e . E n d。结果如何？脚 本程序的后一半将不会被执行。通过观察前一半的工作性能，可以知道瓶颈是在前一半，还 是在后一半，或者是平均分布在两部分之中。假设没有了后一半脚本程序，得到每秒 1 0 0个请 求而不是1 0个，现在就知道了是后一半的某些东西降低了速度。如果得到的结果与“开始点” 接近，说明第一部分有些问题。 现在，移动R e s p o n s e . E n d到可能出故障的那一半脚本程序的中点，然后重新运行强度工 具。我们尽力识别产生最大影响的数据库调用和脚本程序。在我们的例子中，在有 1 0 0行的脚 本程序的第5 0行处中止它。看到每秒请求从 1 0增加到了1 0 0。所以，下一步把Response.End 放 置在第7 5行然后重新测试。如果工作性能又降回去，可以下结论：问题出现在第 5 0行和第7 5 行之间。因此，可以 R e s p o n s e . E n d插在这两点之间，即插在第 6 2行，并重新测试。通过这种 方法，可以查出到底是哪里降低了脚本程序的速度。 如果脚本程序代码的测试数据是线性的又会怎样呢？完全有可能在进行这种测试后，没 有找到特殊问题。在这种情况下，需要确定正在做的事是不是计算量太大了。也许，一些需 要解释的脚本代码应该被调用 C O M对象所取代，因为这样执行起来较快，参见 2 6 . 3 . 1 0节。 26.3.4 会话和应用程序状态 A S P通过较小的框架提供了许多方便，如 I S A P I。对应用程序和会话状态的透明支持是 A S P值得注意的一个特征。 H T T P是一种无状态的协议，所以状态可以被任何用户的两个不同 请求共享。这使 H T T P非常可扩展，因为客户和服务器的一次连接不会持续几分钟或几小时。 为了保持会话状态， A S P在每一个响应的报头加上一个 ASPSESSIONID cookie，在客户随后 的请求中，报头都会包含这个 ASPSESSIONID Co o k i e，A S P就可以利用这个标志，在会话状 态数据库中进行查找。会话状态对于在网上采购应用程序尤其有用。一个来到在线商店的顾 客在采购筐中加入项目。当他决定购买时， A S P就为他们清点商品数目，计算价格。 不幸的是会话状态有一些问题。在我们研究它的缺点之前，让我们来看看它的优点： • 使用起来简单、方便。 第26章 优化ASP 的性能计计789 下载
790sp3高级程 下载 跨请求缓存信息。只计算一次而且把数据存储在 Session对象中,而不是对每一个请求重 复复杂的计算或在数据库中查询。这经常会使性能有极大的提高。 ·无须创建定制的基本结构,可以集中精力创建应用程序 ·对于不需要特殊功能或者较大的内存的应用程序来说往往是足够好了。 1.话状态存在的问题 注意不是所有这些问题都影响性能,但大多数影响性能。 会话状态的问题是: 对 cookie过分依赖。不是所有的浏览器都支持 cookie。有时即使浏览器支持,用户却不 愿接受。没有 cookie,会话状态就无法工作。 Cookie munger过滤器可以用于缺少 cookie 的不完善工作环境,更详细的内容后面讨论 会话状态太脆弱。如果没有一致地使用同一种URL,有些浏览器就会认为你使用了两个 不同的应用程序并且发送不同的 cookie。例如,就会认为 与不一样 会话状态串行执行。换句话说就是同一会话的两个不同的请求从来不会被同时执行。 般情况下,这是一个优势。它意味着 Session对象不同于 Application对象,不需要釆用 Lock和 Unlock方法,这使程序简化。然而,串行化执行引发了框架方面的问题,框架执 行的顺序是不确定的。如果其中一个框架花费了较多的时间来执行,其他的框架就要被 挂起来等待它执行完毕。如果这个框架不需要会话状态(即没有用到 Session对象),可 以通过在页面顶部使用<% EnableSession State= False%来使会话状态无效 在会话状态不使用时,仍占用会话状态使用的内存,降低了ASP的速度。如果应用程序 根本不需要会话状态,可在 Internet Service Manager中在应用程序的 Properties页的App options选项卡中将其设置为无效 ·会话状态是非持久性的。如果ASP应用程序发生了崩溃,所有的会话状态和应用程序状 态就丢失了。如果不允许这样,那么必须不断地坚持把重要数据记录到硬盘或数据库 中 会话状态超时。在默认状态,如果20分钟内没有接收到请求,ASP就会自动结束这一会 话状态。如果用户在浏览你的站点的中途去吃午餐,那等他回来时,其会话状态已经被 关闭了 会话状态持续较长的时间。当站点的一个典型用户仅仅使用你的网站的一至二个网页, 然后就离开了。但是,他的会话状态将会内存中被保持20分钟。对于一个繁忙的站点, 每分钟有几百个新的访问者,合计起来就占用了许多内存 ·决不能在你的 Global asa中有空的 Session onend过程。ASP优化会话状态的方法是在接 收的一个请求后,判断其 Session对象是否为空,如果是,则放弃它。这样当用户实际上 并不使用 Session对象时,可以节省大量的内存。但是如果程序中存在 Session onend的 话,由于程序认为这些清理代码有可能需要运行,ASP就无法进行优化处理了。 较大的数组不应存储在 Session或 Application对象中。在 VBScript和 JScript语言中,当 要访问数组中的某一个元素时,都需要一个数组的完整的临时拷贝。例如,存储一个由 100000元素组成的字符串数组,它以美国的邮政编码为序存储美国各地区的天气状态 那么,每次要査找某一个特定区域的天气情况时,在检索那个区域的天气情况之前,必
790计计ASP 3 高级编程 下载 • 跨请求缓存信息。只计算一次而且把数据存储在 S e s s i o n对象中，而不是对每一个请求重 复复杂的计算或在数据库中查询。这经常会使性能有极大的提高。 • 无须创建定制的基本结构，可以集中精力创建应用程序。 • 对于不需要特殊功能或者较大的内存的应用程序来说往往是足够好了。 1. 话状态存在的问题 注意不是所有这些问题都影响性能，但大多数影响性能。 会话状态的问题是： • 对c o o k i e过分依赖。不是所有的浏览器都支持 c o o k i e。有时即使浏览器支持，用户却不 愿接受。没有c o o k i e，会话状态就无法工作。 Cookie Munger过滤器可以用于缺少c o o k i e 的不完善工作环境，更详细的内容后面讨论。 • 会话状态太脆弱。如果没有一致地使用同一种 U R L，有些浏览器就会认为你使用了两个 不同的应用程序并且发送不同的 c o o k i e。例如，就会认为 与 不一样。 • 会话状态串行执行。换句话说就是同一会话的两个不同的请求从来不会被同时执行。一 般情况下，这是一个优势。它意味着 S e s s i o n对象不同于 A p p l i c a t i o n对象，不需要采用 L o c k和U n l o c k方法，这使程序简化。然而，串行化执行引发了框架方面的问题，框架执 行的顺序是不确定的。如果其中一个框架花费了较多的时间来执行，其他的框架就要被 挂起来等待它执行完毕。如果这个框架不需要会话状态（即没有用到 S e s s i o n对象），可 以通过在页面顶部使用 来使会话状态无效。 • 在会话状态不使用时，仍占用会话状态使用的内存，降低了 A S P的速度。如果应用程序 根本不需要会话状态，可在 Internet Service Manager中在应用程序的Properties 页的A p p o p t i o n s 选项卡中将其设置为无效。 • 会话状态是非持久性的。如果 A S P应用程序发生了崩溃，所有的会话状态和应用程序状 态就丢失了。如果不允许这样，那么必须不断地坚持把重要数据记录到硬盘或数据库 中。 • 会话状态超时。在默认状态，如果 2 0分钟内没有接收到请求， A S P就会自动结束这一会 话状态。如果用户在浏览你的站点的中途去吃午餐，那等他回来时，其会话状态已经被 关闭了。 • 会话状态持续较长的时间。当站点的一个典型用户仅仅使用你的网站的一至二个网页， 然后就离开了。但是，他的会话状态将会内存中被保持 2 0分钟。对于一个繁忙的站点， 每分钟有几百个新的访问者，合计起来就占用了许多内存。 • 决不能在你的G l o b a l . a s a中有空的S e s s i o n _ O n E n d过程。A S P优化会话状态的方法是在接 收的一个请求后，判断其 S e s s i o n对象是否为空，如果是，则放弃它。这样当用户实际上 并不使用S e s s i o n对象时，可以节省大量的内存。但是如果程序中存在 S e s s i o n _ O n E n d的 话，由于程序认为这些清理代码有可能需要运行， A S P就无法进行优化处理了。 • 较大的数组不应存储在 Session 或 A p p l i c a t i o n对象中。在V B S c r i p t和J S c r i p t语言中，当 要访问数组中的某一个元素时，都需要一个数组的完整的临时拷贝。例如，存储一个由 100 000元素组成的字符串数组，它以美国的邮政编码为序存储美国各地区的天气状态。 那么，每次要查找某一个特定区域的天气情况时，在检索那个区域的天气情况之前，必
a-pub.com 第26章优化ASP的性能 791 须把这个有100000个元素的数组整个拷贝到一个临时数组中。通常采用特殊的存取方 法将较大的数组分割成一个个较小的数组,以便减少存储空间。 ·会话状态无法扩展到Web阵。会话状态被限制到运行于一台机器的一个应用程序中。如 果网站升级至Web阵,就既可以获得较高的可用性又可以应付更多的业务量,但是会话 状态不能在Wcb阵中跨机器共享。在这种情况下,可以选择 1)放弃会话状态。这是最简洁和最容易实现的解决方法。 2)定制一个会话状态解决方案。最重要的是把所有状态保存到一个共享的后端数据库 总是使数据长期有效 3)使用“粘性会话”。大多数的硬件和软件重定向器都有一个特征,通过这个特征一个由 有特定IP地址的用户发来的请求,可以被定位于同一台服务器。然而,这相对于根据工作量 均衡负载难于扩展。因为不同的服务器由不同的工作速度。更糟糕的是,粘性会话并不总能 工作。例如,美国在线(AOL)有巨大的代理服务器组,这些服务器有许多个不相同的IP地 址。无法保证,来自AOL的同一个客户的两个连续的请求会通过同一个代理服务器发送而且 有相同IP地址。同样,如果不同的用户使用同一个代理服务器,他们看起来就好像来自同 个IP地址处。 单元线程组件将会话锁定于特定的工作者线程。ASP保存工作者线程的集合。通常,当 一个请求到达请求序列的排头时,第一个可利用的线程就对它进行处理。如果某个会话 被锁定于某个线程,如果该线程正忙于处理别的请求,这个请求必须在该服务器处等待 直到它可被响应为止。这就像在超市购物,虽然其他的收款处前等待付费的队伍较短 却总是到3号收款处排队结账。不要在 Session对象中使用单元线程对象,只使用其他灵 活对象,如中立线程对象或双线程对象加上自由线程调变器 ·已连接的记录集不要存储在 Session或 Application对象中。如果不打算在ASP页面结束 前破坏记录集,那就要及时断开记录集与服务器的连接,否则会消耗巨大的资源。 上面列出了使用会话状态的许多问题。那么,如何才能避免这些问题呢 2.会话状态的替代 我们已经列出了脆弱性、可扩展性和资源消耗等方面的问题。如何解决这些问题? ·完全地避开会话状态。这就绕开了所有会话状态的问题,而且还使应用程序更具有可扩 展性。不过,对需要会话状态的网站来说,这样做是不实际的 在 cookie中直接对会话状态进行编码,而不是存放 ASPSESSIONID。这种方法非常有效, 尤其是当应用在Web阵上时。不过,这有许多的不足之处 1)浏览器必须支持 cookie,并且 cookie在浏览器中启用了 2) cookie有大小的限制,一台浏览器能存储不超过300个 cookie,每个服务器20个,每个 0oke不超过4KB。 3)把会话状态存储在用户的计算机上是不安全。而且,它会随每个请求而在网络内来回 地传送。 ·在 cookie中存储一个后端数据库的键。这种做法是可扩展的并且比较安全,但是它每次 都会查询数据库,而且,它仍然需要在浏览器上启用 cookie. site Server附带的 Active User Object会为你办妥这些事。有些等三方软件商,例如 Software artisans,卖类似的 组件
须把这个有100 000个元素的数组整个拷贝到一个临时数组中。通常采用特殊的存取方 法将较大的数组分割成一个个较小的数组，以便减少存储空间。 • 会话状态无法扩展到Web 阵。会话状态被限制到运行于一台机器的一个应用程序中。如 果网站升级至Web 阵，就既可以获得较高的可用性又可以应付更多的业务量，但是会话 状态不能在Web 阵中跨机器共享。在这种情况下，可以选择： 1) 放弃会话状态。这是最简洁和最容易实现的解决方法。 2) 定制一个会话状态解决方案。最重要的是把所有状态保存到一个共享的后端数据库， 总是使数据长期有效。 3) 使用“粘性会话”。大多数的硬件和软件重定向器都有一个特征，通过这个特征一个由 有特定I P地址的用户发来的请求，可以被定位于同一台服务器。然而，这相对于根据工作量 均衡负载难于扩展。因为不同的服务器由不同的工作速度。更糟糕的是，粘性会话并不总能 工作。例如，美国在线（ A O L）有巨大的代理服务器组，这些服务器有许多个不相同的 I P地 址。无法保证，来自 A O L的同一个客户的两个连续的请求会通过同一个代理服务器发送而且 有相同I P地址。同样，如果不同的用户使用同一个代理服务器，他们看起来就好像来自同一 个I P地址处。 • 单元线程组件将会话锁定于特定的工作者线程。 A S P保存工作者线程的集合。通常，当 一个请求到达请求序列的排头时，第一个可利用的线程就对它进行处理。如果某个会话 被锁定于某个线程，如果该线程正忙于处理别的请求，这个请求必须在该服务器处等待， 直到它可被响应为止。这就像在超市购物，虽然其他的收款处前等待付费的队伍较短， 却总是到3号收款处排队结账。不要在 S e s s i o n对象中使用单元线程对象，只使用其他灵 活对象，如中立线程对象或双线程对象加上自由线程调变器。 • 已连接的记录集不要存储在 Session 或 A p p l i c a t i o n对象中。如果不打算在 A S P页面结束 前破坏记录集，那就要及时断开记录集与服务器的连接，否则会消耗巨大的资源。 上面列出了使用会话状态的许多问题。那么，如何才能避免这些问题呢？ 2. 会话状态的替代 我们已经列出了脆弱性、可扩展性和资源消耗等方面的问题。如何解决这些问题？ • 完全地避开会话状态。这就绕开了所有会话状态的问题，而且还使应用程序更具有可扩 展性。不过，对需要会话状态的网站来说，这样做是不实际的。 • 在c o o k i e中直接对会话状态进行编码，而不是存放 A S P S E S S I O N I D。这种方法非常有效， 尤其是当应用在We b阵上时。不过，这有许多的不足之处： 1) 浏览器必须支持c o o k i e，并且c o o k i e在浏览器中启用了。 2) cookie有大小的限制，一台浏览器能存储不超过 3 0 0个c o o k i e，每个服务器2 0个，每个 c o o k i e不超过4 K B。 3) 把会话状态存储在用户的计算机上是不安全。而且，它会随每个请求而在网络内来回 地传送。 • 在c o o k i e中存储一个后端数据库的键。这种做法是可扩展的并且比较安全，但是它每次 都会查询数据库，而且，它仍然需要在浏览器上启用 c o o k i e。Site Server 附带的A c t i v e User Object 会为你办妥这些事。有些等三方软件商，例如 Software Artisans，卖类似的 组件。 第26章 优化ASP 的性能计计791 下载
