第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。例如,就会认为< A HREF=“/wrox/ bar. asp”> 与< A HREF=“/wox/ Quux. asp”>不一样 会话状态串行执行。换句话说就是同一会话的两个不同的请求从来不会被同时执行。 般情况下,这是一个优势。它意味着 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。例如，就会认为< A HREF =“/ w r o x / b a r. a s p”> 与 <A HREF =“/ w r o x /Qu u x . 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元素组成的字符串数组，它以美国的邮政编码为序存储美国各地区的天气状态。 那么，每次要查找某一个特定区域的天气情况时，在检索那个区域的天气情况之前，必
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 下载