ASP_3高级编程--第26章___优化ASP的性能

下载 第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页面时，一般会紧跟着发出与图片和网页有关的独立请 求，其中图片一般都标有< I M G >的标记。这些紧密联系着的请求被视为一个页面请求。 另一个近似衡量吞吐量的方法是客户数量除以客户的“思考时间”。例如，假如有 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很容易饱和，相对较低 第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） 的统计纪录。 网络延时是一个数据包从一个地方传送到另一个地方的时间，它受以下几个因素的影响： 网络拥挤度、链路的质量、链路的带宽、链节点间的物理距离，与目的地之间的中继站或区 域的个数和在路由器和网关的等待时间。 延时既受到请求从客户端传递到服务器端的时间的影响，也受到从服务器端到客户端返 回响应的时间的影响。在大多数情况下，响应时间既不受客户控制也不受服务器控制。 窄带设备，例如调制解调器，延时更长。相反，宽带设备通常延时较少，不过并非总是 如此。两个通过微波、卫星连接的系统，每秒可以传递几百万比特的数据，但如果仅把单个 数据从一个终端经卫星传送到另一个终端的话，花费的时间比在局域网内传输要长。 即使从客户端到服务器的延时为零，任何一个请求在排队等待接受服务器处理时仍要花 费时间。请求排队时间取决于队列的长度和服务器处理每个请求的时间。队列的长度与服务 器的负荷成比例。 请求执行时间是响应时间的最后一个组成部分。它是唯一的一个服务器可以控制的量。 较长的处理时间会减低吞吐量。减少执行时间是本章的主要任务。 业务量特性曲线 另一个概念是业务量特性曲线，业务量曲线在一天内并不平坦。地区性的新闻网站在清 晨、午饭时间和傍晚会有较重的业务量，但在半夜却非常闲，这时其主要读者已经睡着了。 在业务较重的时间，服务器可能要处理三到五倍于 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 高级编程 下载 第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中的性能 改善情况。 图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 性能提高 进程 内 进程 外 进程 内 进程 外 进程 内 进程 外 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 下载 或网络饱和。 给出可持续的服务器吞吐量的上限，用平均负荷来测试网站性能看是否达到这一目标。 平均负荷量应该根据原始数据或猜测值来模拟。在可能的峰值负荷下测量网站的工作性能可 以检测机器在最繁忙的情况下工作得如何。 如果网站性能达不到要求，就需要找出影响性能的最主要问题，然后解决它。在找到和 解决了这个问题后，应该重新进行测量，重新调整，直到获得了满意的性能或从机器中榨取 出最后一点性能为止。如果还不满意，还可以选择： • 增加新硬件。 • 重新现实地确定性能指标。 • 把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 高级编程 下载 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 下载 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。例如，就会认为< A HREF =“/ w r o x / b a r. a s p”> 与 不一样。 • 会话状态串行执行。换句话说就是同一会话的两个不同的请求从来不会被同时执行。一 般情况下，这是一个优势。它意味着 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对象），可 以通过在页面顶部使用 <% EnableSessionState = False %>来使会话状态无效。 • 在会话状态不使用时，仍占用会话状态使用的内存，降低了 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元素组成的字符串数组，它以美国的邮政编码为序存储美国各地区的天气状态。 那么，每次要查找某一个特定区域的天气情况时，在检索那个区域的天气情况之前，必 须把这个有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 下载 • 把名称 /值对存储在 U R L查询字符串中。例如， 。这种做法适合所有浏览器，但它会暴露会 话状态的内容，而且不能很好地支持 P O S T和窗体器。 • 修改U R L，使会话状态可以在 U R L（而不是查询字符串）中编码。 A m a z o n . c o m就是这 样做的一个网站。另一个例子是 G e o rge Reilly 写的Cookie Munger过滤器，它是P l a t f o r m S D K（Software Development Kit,软件开发工具包）中的一个 I S A P I过滤器示例。这个过 滤器使得A S P会话状态能在不支持c o o k i e s的浏览器上工作。过滤器检查服务器和浏览器 之间传送的所有数据，从报头去掉ASPSESSIONID cookie，然后修改网页内所有的U R L， 这样最后看起来就像 。它也 在所有收到的请求中寻找U R L，并把它们翻译成符合普通 U R L标准，同时给它们加上一 个Cookie 报头。所有这些在幕后完成，A S P对此一无所知。Cookie Munger 存在两个问 题，像其他原始数据过滤器一样，会导致性能的根本性降低。而且，当 c o o k i e丢失后， 过滤器对纯H T M L文件（.htm 文件）不起作用。请参阅相关文档。 • 窗体包含隐藏字段，这些隐藏的字段是对状态的编码。这样做效果还不错，不过，它要 求每一页都是一个窗体（或者使用查询字符串）。如果使用浏览器上的 Back 按钮，数据 有可能会丢失。当用户查看网页源代码时，就可以看到隐含的字段，所以它对私有数据 并不合适。 简而言之，所有这些改变的效果都不是很好。 对于以上的对A S P的会话状态阐述，不应完全失去信心。这里不得不说，使用 A S P会话对 许多应用程序来说是一种明智的选择。如果不太介意以上的缺点，就可以使用。当然，在你 的网站开始流行并逐渐增加业务量时，那些缺陷会就会带来一些麻烦。尤其是移植到 We b阵 时，可能被迫做一些代价昂贵的工作。 3. 应用程序状态 就像会话状态，应用程序状态同样有一些很好的优点和巨大的缺点。在 A p p l i c a t i o n对象 中缓存数据可以使性能显著提高。它不是为了每一个会话状态或请求对同样数据进行一遍又 一遍的重复计算，而是只计算一次数据并把它们存储在 A p p l i c a t i o n对象中。 跟S e s s i o n对象一样，A p p l i c a t i o n对象的状态不是永久的，且不能在系统崩溃后挽救。应 用程序状态适合于一台计算机的情况，但不适合 Web 阵。这表明只有只读数据应被缓存于应 用程序状态中，因为通过We b阵更新共享数据是困难的。应用程序状态并不依赖于 c o o k i e，因 此，也就没有与c o o k i e相关的问题要探讨。大的数组不应该被存储在应用程序状态中，因为每 次访问数组中的任何一个元素时，按 V B S c r i p t和J S C r i p t的机制需要给整个数组做一个临时的 拷贝。 应用程序状态不应包含单元线程对象，因为这会导致严重的性能瓶颈。事实上，为了不 鼓励用户使用单元线程对象， A S P不允许用S e r v e r. C r e a t e O b j e c t创建这种对象。如果一定要在 应用程序范围存储单元线程对象的话，就必须使用 < O B J E C T >标记，如： 之所以不应把单元线程对象存储应用程序范围内，原因有三： 792计计ASP 3 高级编程 下载 • 对象存放在特殊的S TA单元中，所有的对象调用都必须从对象的单元调度到工作者线程 的单元，这比直接调用对象要慢得很多。 • 所有对对象的调用都是串行的，所以每次仅一个调用者可以使用对象，这就会导致有许 多的工作者线程排队等候访问该对象。存储在应用程序范围的对象应该被并行使用。 • 存储在应用程序范围内的单元线程对象从不会在调用者的安全环境中执行。 只有灵活对象可以存储在应用程序范围内。灵活对象允许直接调用，不会使调用者排队 等待。灵活对象编写困难，因为必须要特别注意线程安全。可以用 C + + / AT L或Visual J++来编 写。 26.3.5 安全套接字层 通过H T T P S协议访问安全套接字层 S S L，可以完成安全的电子商务，在浏览器和服务器 之间开辟了一条安全的连接，并且所有的数据在通过电缆传送出去之前，都会被编码加密。 这样就使得在 I n t e r n e t等不可信赖网络上传送信用卡帐号和医疗记录等敏感数据变得较为安全。 由于实现加密、解密需要进行大量数学计算，所以 S S L连接比通常的H T T P连接要复杂得 多。用H T T P S传输静态文件的费用是用H T T P的2 0多倍。经H T T P S传送A S P网页与用它传递静 态文件相比费用要少些。可是由 A S P产生动态网页却比传送静态文件要昂贵得多，因此在 H T T P S上的花费只占总费用的很小的一部分。相比之下，对一些小型的 A S P网页来说，在 H T T P S上的花费仍是很大的。S S L可使吞吐量减小到数十分之一。 因为S S L费用这么高，只有在必需时才使用它。信用卡帐号必须用 H T T P S形式来传递； 医疗记录也必须用 H T T P S网页来提供。主页和其他不含私人内容的网页应该用 H T T P来传递。 除了一些含有机密内容的图片外，所有的图片都不应该用 H T T P S方式来传递。但是，对于连 接到H T T P S页面，如果试图通过 H T T P检索数据，大多数的浏览器会自动弹出一个消息窗口。 一个较慢的页面也比得到一个消息窗口的页面要好得多。 26.3.6 进程隔离 在IIS 3.0中，所有的A S P应用程序都在 I I S的核心 inetinfo.exe 内被处理。这是很快的却是 易受干扰的。一个错误的组件可以使整个We b服务器系统崩溃。IIS 4.0引入了进程隔离的方法。 应用程序既可以在进程内（在 inetinfo 进程内）运行，也可以在进程外（由 m t x . e x e作宿主） 运行。一个运行在进程外的错误的组件能够破坏其宿主，却不能破坏 We b服务器的核心。然 而，由于进程外应用程序需要与 i n e t i n f o通信，它的运行速度要慢些。性能的降低换来了可靠 性的提高。 进程会消耗大量的系统资源，所以不能在 IIS 4.0上运行几十个进程外的应用程序。由于意 识到了这一点，在 IIS 5.0中加入了隔离级别，可以缓冲进程外。在较高隔离级别的（进程外 的）应用程序继续在独立的进程中运行，这些进程以 d l l h o s t . e x e作宿主。在中等隔离级别的 （共享进程外的）应用程序在一个进程内一起运行，且也以 d l l h o s t . e x e作宿主。低等隔离级别 的（进程内的）应用程序直接由 I I S的核心来处理，这个核心就是 i n e t i n f o。 在IIS 5.0中，大大地提高了A S P的性能，其进程外应用程序的性能比 IIS 4.0中的进程内应 用的性能还要好，进程内应用程序的性能则更佳。因此，可以牺牲一些性能来换取系统的可 靠性。新的应用程序在缺省状态下在中等隔离级别中运行；而在 IIS 4.0中，新的应用程序在 第26章 优化ASP 的性能计计793 下载 进程内运行。 如果有一个受信任的应用程序（即由已测试过的组件组成），则可以把它放置在低隔离级 别中运行以提高它的性能。需要注意的是，该应用程序崩溃会使 We b服务器进程崩溃。 IIS 5.0 包含有一个新的可靠的重启动特性，由 iisreset.exe 控制。该功能已经比 IIS 4.0中的同类功能少 了许多问题，但仍然不很理想。 26.3.7 缓存技术和字典 缓存是提升基本性能的技术。它用空间换取速度。为了不重复计算数据或从远处获取数 据，把数据暂存以便再使用。计算机的每一层都十分依赖于缓存，从 C P U的L 1和L 2缓存到硬 盘的缓存，到操作系统的文件缓存，到 A S P缓存，到O D B C的连接缓冲。 在A S P中可以通过四种方法来利用缓存： 第一种方法是把一些数据存储在变量中而在同一页中重新使用它们。例如，一个字符串 或一个记录集。 第二种方法是把一些数据存储在 S e s s i o n对象中，这样（同一用户在同一会话中）在访问 其他网页时通过这个S e s s i o n对象可以重新使用这些数据。例如，购物清单或用户名等。 第三种方法是把数据存储在 A p p l i c a t i o n对象中，这样，数据可以被本站点的许多访问者 使用。例如，网页的标题栏。 最后一种方法是用一个组件来缓存全局数据，当该组件在一个网页上创建时，它的方法 访问内部的数据。例如，一个 Browser Capabilities组件缓存了b r o w s c a p . i n i的内容，仅当硬盘 上的文件改变时才更新它的缓存，这种工作只需几个月进行一次。 字典也称为“相关数组”或“映射”，对于缓存名称 -值对是非常有用的。例如，可以用 两个字母的国家代码映射其全称。如“ F R”·“F r a n c e”，“I E”·“ I r e l a n d”，等等。因为这 些数据仅仅在有一个新国家成立时才发生改变，所以把这个字典缓存于 A p p l i c a t i o n对象中是 十分合适的。 另一个例子就是 I S B N号码，包含单位名称及其详细情况。因为 I S B N号码有成千上万个， 而且每天还会新增几千个。这些数据太大了，所以不可以存储在内存中，最好存储在数据库 中，并定期更新缓存中的数据。不过为在线书店的购物清单建立一个 ISBN 和其详细情况的映 射是合适的。 A S P含有一个D i c t i o n a r y组件，S c r i p t i n g . D i c t i o n a r y。但是，S c r i p t i n g . D i c t i o n a r y是单元线 程的，不适合存储在S e s s i o n对象或A p p l i c a t i o n对象中。 对于商业服务器，可以使用 C o m m e r c e . D i c t i o n a r y。它包含两个可以自由使用的字典： L o o k u p Ta b l e和C a p r o c k . D i c t i o n a r y。 A s p t o d a y.com 站点上有一本关于L o o k u p Ta b l e字典的好教材。 如果要在S e s s i o n对象或A p p l i c a t i o n对象中缓存一个记录集，首先确保断开它的连接。 跨多个网页保持连接是一个非常不好的想法。 更好的是，如果记录集总是被转换成相同的 H T M L（例如表或列表框），缓存H T M L文件 内容可以避免每次在记录集中遍历的时间花费。如果列表框在不同的环境下有不同的选项集， 仍然可以缓存列表框，并且使用 R e p l a c e函数通过适当的选择来产生一个新的字符串。 794计计ASP 3 高级编程 下载 26.3.8 数据库性能 对于数据库的定义，一些著名的计算机公司经理的解释为：“数据库就是We b应用程序”。 动态的站点不断地存储、检索和更新数据。数据库的性能常常是网络应用程序本身性能的核 心部分。有几种简单的方法可以减少网络应用程序使用数据库的瓶颈。努力调整数据库的性 能更为人们所重视。企业数据库甚至提供分析使用模式的工具以便帮助开发者和管理者。 微软公司的SQL Server 是我们的网络应用程序使用的数据库，也是我们这里所 指的数据库。大多数情况是这样，如果有例外，另外指明。 要做的第一件事就是不要在网络应用程序中使用 Microsoft Access。A c c e s s在其的范 围内使用时，是一个很好的应用程序。然而，却不利于快速传送大量数据。最好将其在 D a t a Sources 面板中的驱动程序也删除。 在缺省状态下， A D O被设置成单元线程的。这可能是由于 A c c e s s仅支持通过O D B C驱动 程序的单元线程访问。 A D O支持多线程模型，使用这种方式可以使性能提高。有一个批处理 文件可以用来进行这样的转换。在典型安装的情况下，可以在 \ Program Files\Common Files\System\ado 目录下找到它。在此路径下运行m a k e f r e l 5 . b a t，A D O可以转换成双线程对象， 同时支持单元线程模型和自由线程模型。同样，也有一个批处理文件可以返回单元线程模型。 当使用的A D O是2 . 5版时，其批处理文件及 D L L文件名中的“1 5”很容易把人搞 糊涂，因为1 5表示1 . 5版。D L L文件中的C O M能力改进了，但D L L文件仍然继承低版 本的名字。这尽管不直观，但这比相同的组件在不同的版本中使用不同的名字好。 尽管各个企业数据库的管理系统不尽相同，但它们仍然有一个共同之处：为了使其获得 较高的性能，需要足够的内存。如果有足够的内存支持缓存， I I S的表现也会更好。正因为此， 把I I S和S Q L分开放在不同的机器上是一个好主意。许多人马上就会想到由于计算机间的传输 问题会使系统的性能下降。然而，从使用情况看，大容量的内存、专用的处理能力及良好的 低层通信方法使得对数据库的访问速度极快。 如果数据库运行在一台独立机器上，使用数据库有两个可行的方案，两者都能提高网络 应用程序的性能。 第一，应用程序几乎全由数据库来驱动。在这种情况下，数据库需要足够的资源来有效 处理查询和缓存数据 . 第二个方案是另一个极端，很少使用从数据库来的数据。在这种情况下，把数据库独立 放在另一台机器上仍然十分有意义。这将使得处理主要业务量的网络服务器的资源不被数据 库占用。跨机器边界所付出的代价多于提高数据库和网络服务的效率所付出的代价。 一个数据库经常可以同时处理几个网络服务器的请求。 利用C O M +的特性，包括以前的 M T S，可以处理一些数据检查的工作。通过利用置于数 据库定义内的引用完整性校验，不用启动脚本显式地检查就可以找出相应的错误。利用 We b 页的事务可以进一步保护数据库数据的更新和插入。引用完整性检查在数据库中执行得要比 在脚本中快得多。例如，检查用户现在的地址提供的邮政编码和服务器提供的邮政编码表。 另外，要确保索引存在于被访问的表中。数据库引擎能做一项神秘的工作：当得知数据 库如何被访问的某些线索后，系统能自动调整性能。这些线索由已经建立起来的索引提供。 第26章 优化ASP 的性能计计795 下载 796计计ASP 3 高级编程 下载 发挥数据库中存储过程的优势：经常需要的例行程