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 下载