使用-application对web进行压力测试

1、使用Web Application Stress Tool 对web 进行压力测试你的 Web 服务器和应用到底能够支持多少并发用户？在出现大量并发请求的情况下，会出现问题吗？这些问题靠通常的测试是无法解答的。本文介绍 了为这个目的而提供的免费工具WAS 及其用法。另外，本文介绍了一种 Web 应用的性能优化方法，并利用WAS 测试了它的性能改善程度。随着服务器端处理任务的日益复杂以及量的迅速增长，服务器性能的优化也成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。的 Web Application Stre

2、ss Tool（WAS，Web 应用负载测试工具）本文介绍在 Web 服务器性能测试中的应用（注：Stress 基本含义为“重压；压力”等，本文称之为“负载”）。另 外，还将通过 WAS 评估一种相对简单的性能改善方法，这种方法的基本是在服务器上生成静态的 HTML 页面、避免过多的数据库调用。负载测试是任何 Web 应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的ranet，测试能够出最终会导致服务器的内存以及竞争情况。无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未来的代码优

3、化、硬件配置以及系统升级带来方便。即使经费有限的开发组 织也可以对它们的进行负载测试，因为的WAS 是可以免费的。WAS 要求 WindowsNT 4.0 SP4 或者更高，或者Windows 2000。为了对台或者多台客户机模拟大量用户的活动。WAS 支持进行负载测试，WAS 可以通过一s，也能够模验证、加密和拟各种浏 览器类型和 Modem 速度，它的功能和性能可以与数万的产品相媲美。如果你对 WAS 和的差别感，可以的另外一个测试工具Web CapacityWeb 工具的比较页面。ysis Tool （WCAT）之间进行负载测试首先必须创建WAS要对之一创建模拟用户活动。可以用下面四种方

4、法：通过浏览器的活动；通过导入 IIS 日志；通过把WAS 指向 Web的内容；或者手工制作。图 1 所显示的是通过浏览器事件生成的的一部分，是的Duwamish Book Store。Duwamish 是开发的电子商务 Web 应用示例，从Duwamish的“Phase 4”可以这个包。包中包含了它自己的WAS 测试。【图 1】制作 WAS是相当简单的，不过要制作出模拟真实用户活动的有点儿复杂。如果你已经有一个运行的 Web，可以使用 Web 服务器的日志来确定Web上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。图 1 这个中假定有 30 个会员在浏览书店，同时

5、又有一个会员正在。要模拟两者混合而成的行为，首先必须创建页面组并在的 Page Group 分枝确定点击分布情况。在 Page Group 分枝中的分布。图 2 显示了 grp_browse 和 grp_buy 这两个页面组以及 30 比 1 的流量分布可以增加、修改或删除页面组，也可以为各个组修改流量图 2】创建了页面组之后，就可以在主视图中赋予各个请求不同的页面组，如图 3所示。为每个请求指定页面组相当于告诉 WAS 如何分布流量。记住在本例中对 grp_buy 组页面的请求约占总数的 3%，而对 grp_browse 组页面的请求约占 97%。【图 3】如果需要在查询字符串中传递“名字-

6、值”对，可以用 WAS 的查询字符串编辑器来定义各个变量的所有可能的值。在输入变量值后，既可以要求 WAS 顺序地使用 变量的各个值，也可以要求WAS 在请求时随机选择变量值。这在一定程度上增加了所模拟行为的真实可以调整测试配置性，也可以帮助避免缓冲对的影响准备好测试之后，以便观察不同条件下的应用性能。图 4 是WAS 的设置界面【图 4】Stress Level 和 Stress multipr 这二个项决定了服务器的并发连接的数量。建议不要选择超过 100 的 Stress Level 值。如果要模拟的并发连接数量超过 100个，可以调整 Stress multipr 或使用多个客户机。在

7、负载测试期间 WAS 将通过 DCOM 与其他客户机协调。有关在测试中使用多个客户机的/kb/hkb13.htm。信息，参见s，还要为WAS 提供如果提供个性化服务，要进行验证或使用一个用户目录。WAS 中的用户了发送给服务器的以及服务器 发送给客户端的s。增加用户数量并不增加Web 服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stesss Level 乘以 Stress Multipr）。有关线程、用户、s 相互作/Threads/WASThreads.htm。 本文来用的信息请参见自无涯网:httWAS 允许设置warmup（热身）时间，一般可以设置为 1 分钟。在 warm

8、up 期间 WAS开始执行 ，但不收集统计数据。warmup 时间给 MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在 warmup 时间内收集统计数据，这些操作的开销将影响性能测试结果。设置页 面提供的另外一个有用的功能是限制带宽（throttandwidth）。带宽限制功能能够为测试模拟出Modem（14.k K，28.8 K，56 K）、ISDN（64 K，128 K）以及 T1（1.54 M）的速度。使用带宽限制功能可以精确地接Web 服务器所感受的性能。出客户通过拨号网络或其他外部连要理解这些不同的设置对应用的影响，有必要了解如何使用WAS 收集性能数据。使用 WAS，从Wi

9、ndows NT 和 Windows 2000 机器获取和分析性能计数器（Performance Counter）是很方便的。加入计数器要用到图 5 所示的 Perf Counters 分枝。【图 5】在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个不可能精确地出性能瓶颈所在，但对一般的Web 服务器性能测试来说却是一个好的开始。处理器：CPU 使用百分比（% CPU Utilization）线程：每秒的上下文切换次数（Context Switches Per Second (Total)）ASP：每秒请求数量（Requests Per Second）ASP：请求执行时间（Request

10、 Execution Time）ASP：请求等待时间（Request Wait Time）ASP：置入队列的请求数量（Requests Queued）CPU 使用百分比反映了处理器开销。CPU 使用百分比持续地超过 75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理 ASP。每秒的 ASP 请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉 每秒内服务器成功处理的 ASP 请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要

11、的时间。可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，最终会达到这样一个 点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应的能力，找出这个并 发用户数量开始“压倒”服务器的时间则会增加。要搞清楚硬件和临界点非常重要。置入队列的 ASP 请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM 对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在 ASP 会话对象中了一个单线程的单元组件。运行WAS 的客户机 CPU 使用率也有

12、必要监视。如果这些机器上的 CPU 使用率持续地超过 75%，说明客户机没有足够的资源来正确地运试，此时应该认为不。在这种情况下，测试客户机的数量必须增加，或者减小测试的 Stress Level。本文来自无涯网:htt每次测试运行结束后WAS 会生成详细的报表，即使测试被提前停止也一样。WAS 报表可以从 View 菜单选择 Reports 查看。下面介绍一下报表中几个重要的部分。如果这是一个新创建的测试，你应该检查一下报表的Result Codes 部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了 404代码（页面没有找到），说明在中有错误的页面请求。

13、页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试中各个页面中次 数。TTFB 和 TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB 反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以 毫秒计），TTLB 包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了这里能够介绍的内容。为了给你一个有关表所提供信息种类的印象，图 6 摘录了一个报表实例

14、。【图 6】随着ernet 应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成 本低廉。对于能够适应用户需求不断变动的可定制页面来说，静态HTML 已经退出了舞台，比如内容根据客户请求变化的页面就是其中一例。这一切都要求系统保 存相关的数据，例以及用户可能请求哪些信息的数据。关用户本身紧跟这些趋势的Web 开发者已经开始提供可定制的 Web。象搜索数据之类的任务现在可以由服务器执行而无需客户干预。然而，这些也导致了一个结果，这就是许多都在使用大量的优化的数据库调用，从而使得应用性能大打折扣。可以使用以下几种方法来解决这些

15、问题：优化 ASP 代码。优化数据库调用。.使用过程。调整服务器性能。优秀的设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响 Web的响应速度，这主要是因为在发送页面之前必须单独地为每个的用户进行数据库调用。这里性能优化方案正是基于以下事实：静态 HTML 页面要比那些内容依赖于数据库调用的页面要快。它的基本是：在用户页面之前，预 先从数据库提取信息写入在服务器上的静态 HTML 页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的 生成。当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数

16、据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。为了保证能够在合适的时间更新静态HTML 页面，把下面的代码加入到相应的 ASP 页面前面：随 着ernet 应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本 低廉。对于能够适应用户需求不断变动的可定制页面来说，静态 HTML 已经退出了舞台，比如内容根据客户请求变化的页面就是其中一例。这一切都要求系统保存 相关的数据，例用户可能请求哪些信息的数据。关用户本身以及紧跟这些趋势的Web 开发者已经开始提供可定制的 Web。象搜索数据之类的任务现在可

17、以由服务器执行而无需客户干预。然而，这些也导致了一个结果，这就是许多都在使用大量的优化的数据库调用，从而使得应用性能大打折扣。本文来自无涯网:htt可以使用以下几种方法来解决这些问题：优化 ASP 代码。优化数据库调用。.使用过程。调整服务器性能。优秀的设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响 Web的响应速度，这主要是因为在发送页面之前必须单独地为每个的用户进行数据库调用。性能优化方案正是基于以下事实：静态 HTML 页面要比这里那些内容依赖于数据库调用的页面要快。它的基本是：在用户页面之前，预 先从数据库提取信息写入在服务器上的静态 HT

18、ML 页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的 生成。当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。为了保证能够在合适的时间更新静态HTML 页面，把下面的代码加入到相应的 ASP 页面前面：每当该页面被调用，就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，Update.asp代码发送给浏览器。就会运行；否则，该 ASP 页面把余下的 HTML最后更新时间从 Application 变量得到，它的第一次初始化由

19、global.asa 完成。具体的更新时间间隔应根据页面内容的更新要求调整。如果每次ASP 页面的时候都要提供的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。如果数据库内容由客户通过适当的 ASP 页面更新，要确保静态页面也能够自动反映数可以在 ASP 页面中调用 Update的静态 HTML 页面。据的变化，器上也有了。这样，每当数据库内容改变时服务另一种处理频繁变动数据的办法是借助Microsft SQL Server 7.0 的 Web 助手向导（WebAssistant Wizard），这个向导能够利用 Tran成标准的HTML

20、文件。-SQL、过程等从 SQL Server 数据生利用 SQL Server 任务，Web 助手向导能够用来定期地生成HTML 页面。正如前面概要介绍的方案， Web 助手可以通过触发子更新HTML 页面，比如在指定的时间执行更新或者在数据库数据变化时执行更新。 本文来自无涯SQL Server 使用名为 sp_makewebtask 的网:htt过程创建HTML 页面，它的参数是目标 HTML 文件的名字和待执行过程的名字，查询的输出发 送到 HTML 页面。另外，也的模板文件。 从前面的代码可以看出，当 ASP 页面可以选择使用可供结果数据HtmlMain.asp 需要更新时，控制以

21、ASP 文件的物理路径为参数转到了Update 页面。Update的 任务是用新的 HTML 数据刷新发出调用的 ASP 文件，并把调度 ASP 代码加入到文件的开头。为此，Update打开调度模板文件，拷贝调度 ASP 代 码，然后控制转到了，这部分主要任务是执行数据库操作。Update 用路径参数以写模式打开另一部分HtmlMain.asp 文件，数据库操作的 输出以 HTML 格式写入这个文件。万一用户页面的时候正好在执行更新可以利用锁或者其他类似的机制把页面延迟几秒钟。 HtmlMain.asp（纯 HTML 加调度 ASP 代码）和main.asp（普通的 ASP 文件）在WAS 下

22、进行了性能测试。main.asp 文件要查找 5 个不同的表为页面提取数据。为了和这两个文件相比较，一个只单个表的 ASP 页面（SingleTableTest.asp）和一个纯HTML 文件 （PlainHtml.html）也进行了测试。如下表所示：其中 TTFB 是指Total Time toByte，TTLB 是指 Total Time to Last Byte。这些测试在一台 Windows NT Worksion 4.0 SP6 运行al Web Server 的机器上实施。为了使性能指标更明显，带宽限制到了 14.4 K。在实际环境中数值变化可能很文件名字命中数平均 TTFB（ms

23、）平均 TTLB（ms）PlainHtml.html847474SingleTableTest.asp868.88789.38Main.asp9125.893759.56HtmlMain.asp9149.891739.89大，但这个结果精确地反映了各个页面在性能上的差异。显示单个表的 ASP 页面的处理时间是 720.5ms，而纯 HTML 文件则为427ms。Main.asp 和 HtmlMain.asp 的输出时间相同，但它们的处理时间分别为 3633.67ms和 1590ms。也就是说，在这个测试环境下可以把处理速度提高 43%。要让页面每隔一定的次数更新，比如 100 次，那么这第 1

24、00 个用户就必须等如果待新的 HTML 页面生成。不过，这个代价或许不算太高，其他 99 个用户获得了好处。静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。在大多数情况下，动态页面的生成将在相当大的程度上提高的性能而且无需在功能上有所折衷。虽然有许多大的大量没有必要的数据库调用而采用了这个策略来改善性能，也有许多很差的性能。完全由于进行的WAS 是一个功能非常丰富的服务器性能测试工具，可以帮助准确地判断什么方案将适合于能够显著地改善性能。性

25、能；是否某个方案（比如本文第二部分的静态页面方案）本文对WAS 的介绍应当说是相当粗略和肤浅的。WAS 还提供了一个对象模型，/?ObjM/default.htm可以通过可以看到一个扩展它的功能。示例。这个将登记 Web 服务器的每秒最大请求数量，自动地增加Stress Level 值直到服务器处理器利用率达到 90%为止。WAS 能够为你提供有关 ASP 应用和它所运行的硬件的丰富的信息。在 WAS 上花费一些时间，你就能够更深入地了解你的应用的性能、稳定性、瓶颈和局限性。花费这种时间是值得的。ted 2008-10-14 14:04 liuhaitao 阅读(125) | 评论 (0) |

26、 编辑ASP.NET 性能优化转：http/archive/2006/06/05/417632.html1. 数据库性能优化数据库的连接和关闭数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数据库交换信息以通过验证，比较耗费服务器资源。ASP.NET 中提供了连接池（Connection Pool）改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，

27、从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。使用过程过程是在服务器上的一组预编译的 SQL 语句，类似于DOS 系统中的批处理文件。过程具有对数据库立即的功能，信息处理极为迅速。使用过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。另外，过程在服务器端运行，独立于 ASP.NET 程序，便于修改，最重要的是它可以减少数据库操作语句在网络中的传输。优化查询语句ASP.NET 中 ADO 连接消耗的资源相当大，SQL 语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的 SQL 语句以减少执行时间

28、。比如，不在查询语句中包含子查询语句，充分利用索引等。2. 字符串操作性能优化使用值类型的 ToString 方法在连接字符串时，经常使用+号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱操作转化为类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值到新创建的对象中。使用值类型的 ToString 方法可以避免装箱操作，从而提高应用程序性能。运用 StringBuilder 类String 类对象是不可改变的，对于 String 对象的重新赋值在本质上是重新创建了一个S

29、tring 对象并将新值赋予该对象，其方法 ToString 对性能的提高并非很显著。在处理字符串时，最好使用 StringBuilder 类，其.NET 命名空间是 System.Text。该类并非创建新的对象，而是通过 Append，Remove，Insert 等方法直接对字符串进行操作，通过 ToString 方法返回操作结果。其定义及操作语句如下所示：num;System.Text.StringBuilder str = new System.Text.StringBuilder(); /创建字符串str.Append(num.ToString(); /添加数值 numResponse

30、.Write(str.ToString); /显示操作结果3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要默认情况下，ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。仅对需要的应用程序启用NTLM。大多数情况下，对于需要验证。默认情况下，验证模式为 Windows，或集成验证的应用程序，最好在 Machine.config 文件中禁用验证，并在 Web.config 文件中启用验证。根据适当的请求和响应编码设置来配置应用

31、程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。考虑对应用程序禁用 AutoEventWireup。在 Machine.config 文件中将AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩（例如 Page_Load）。如果页面开发要使用这些事件，需要在基类中重写这些方法（例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法）。如果禁用AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执

32、行它，获得稍许的性能。从请求处理管线中移除不用的模块。默认情况下，服务器计算机的 Machine.config 文件中 节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能要自定义它。检查每个模块及其功能，并按您的需例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从 列表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进入和离开代码。4. 一定要禁用调试模式在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。5. 对于广泛依赖外部资源的应用程序，请考虑

33、在多处理器计算机上启用网络园艺ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程（每个 CPU 一个），并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象（这里只是提及两种可能性），则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。6. 只要可能，就缓存数据和页输出ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求（特别是在站点中

34、预期将有较大通讯量的区域），可以优化这些页的性能。与 .NET Framework 的任何 Web窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的导致缓存中不必要的周转，并且经常导致的代回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的码清除和Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别

35、是当项在到期前被移除时。这也称作内存压力。7. 选择适合页面或应用程序的数据查看机制根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。8. 将 SqlDataReader 类用于快速只进数据游标SqlDataReader 类提供了一种从 SQL Ser

36、ver 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server的本机网络数据传输格式从数据库连接直接数据。另外，SqlDataReader 类实现IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关信息，请参见SqlDataReader 类。有关 ASP.NET 如何据。数据的信息，请参见通过 ASP.NET数9. 将 SQL Server过程用于数据在 .NET Framework 提供

37、的所有数据方法中，基于 SQL Server 的数据是生成高性能、可缩放 Web 应用程序的选择。使用托管 SQL Server 提供程序时，可通过使用编译的过程而不是特殊查询获得额外的性能提高。10. 避免单线程单元 (STA) COM 组件默认情况下，ASP.NET必须在 .aspx 文件内将不允许任何 STA COM 组件在页面内运行。若要运行它们，pat=true 属性包含在 Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程

38、的任何调用。使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何erop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，的信息。另外，在页面构造时将实例化由某个线程创建的ponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA之间的封送处理。和 STA线程Dimp as newponent()Public Sub Page_Load()p.Name = BobEnd Sub首选机制是推迟对象的创建，直到以后在S

39、TA 线程下执行上述代码，如下面的例子所示。DimpPublic Sub Page_Load()p = newponent()p.Name = BobEnd Sub的做法是在需要时或者在 Page_Load方法中构造任何 COM 组件和外部资源。不要将任何 STA COM 组件在可以由构造它的线程以外的其他线程的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生 的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为

40、 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。11. 将调用密集型的 COM 组件迁移到托管代码.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能之一是将数据

41、从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外，一处理完任何 COM 对象或本机资源就它们。这样，其他请求就能够使用它们所引起的性能问题。它们，并且最大限度地减少了因稍后请求回收器12. 在 Visual Basic .NET 或 JScript 代码中使用早期绑定喜欢使用 Visual Basic、VBScript 和 JScript 的原因之一就是它们所以往，开发谓“无类型”的性质。

42、变量不需要显式类型，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 Page 指令中，或者，对于用户控件，请将该属性包括在 Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。JScri

43、pt .NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：被显式为 Object。是无类型的类的字段。是无显式类型的函数或方法成员，并且无法从其使用推断出类型。最后一个差别比较复杂，因为如果 JScript .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。var A;var B;A = o;B = World;B = 0;JScript .NET 变量时，请为其分配一个类型。例如，var为了获得最佳的性能，当A : String。13. 使请求管线内的所有

44、模块尽可能高效请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。15. 必要时调整应用程序每个辅助进程的线程数ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请

45、求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库或 XML Web servi请求时，页面请求通常停CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是止并的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子

46、是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件 节点的maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。注意 辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web servi的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对

47、于有一个或两个处理器的计算机，默认值就可以，但对于有处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注意 进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在线程而不是处理请求上。16. 适当地使用公共语言运行库的回收器和自动内存管理不要给每个请求分配过多内存，因为这样回收器将必须更频繁地进行的工作。另外，不要让不必要的指针指象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致的工作。特别是在 Finalize 调用中不要资源，因为资源在被回收器回收之前可能一直消耗着内存。最后这个问题经常会对

48、Web 服务器环境的性能造成易耗尽某个特定的资源。性的打击，因为在等待 Finalize 运行时，很容17. 如果有大型 Web 应用程序，可考虑执行预批编译每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集新的程序集要快。一页比每页加载批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能

49、较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次页面及其程序集将已被编译。您的站点时，没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有的编译器进程（例如 csc.exe（C# 编译器）或 vbc.exe（Visual Basic 编译器）启动。还应尽量避免更改应用程序的 bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以

50、在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中（每个目录最多几百页）以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。18. 不要依赖代码中的异常因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。tryresult = 100 / n

51、um;catch (Exception e)result = 0;/ .to this.if (num != 0)result = 100 / num;elseresult = 0;19. 使用 HttpResponse.Write 方法进行字符串串联该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write用连接字符串更快。方法的单个调Response.Write(a);Response.Write(myString);Response.Write(b);Response.Wri

52、te(myObj.ToString();Response.Write(c);Response.Write(myString2);Response.Write(d);20. 除非有特殊的原因要关闭缓冲，否则使其保持打开禁用 Web 窗体页的缓冲会导致大量的性能开销。21. 只在必要时保存服务器控件视图状态自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值（您不需要编写任何代码）。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服

53、务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的EnableViewSe 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。您还可以使用 Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用：注意 Control 指令中也支持 EnableViewSe 属性，该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量，请（通过将 trace=true 属性包括在 Page

54、指令中）启用该页的并查看 Control Hierarchy 表的 Viewse 列。有关和如何启用它的信息，请参见 ASP.NET。22. 避免到服务器的不必要的往返过程虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，只有在检索或数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其那么您不应该编写导致往返过程的代码。在数据库中，如果您开发自定

55、义服务器控件，请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web服务器的次数。使用 Page.IstBack 避免对往返过程执行不必要的处理如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的，使用 Page.IstBack 属性有条件地执行代码。例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。void Page_Lo

56、ad(Objecder, EventArgs e)/ Set up a connection andd here.if (!Page.IstBack)String query = select * from Authors whereName like %JUSTIN%;mand.Fill(ds, Authors);myDataGrid.DataBind();由于每次请求时都执行 Page_Load 事件，上述代码检查 IstBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事

57、件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。23. 当不使用会话状态时禁用它并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。若要禁用页的会话状态，请将 Page 指令中的 EnableSesSe 属性设置为false。例如:注意 如果页需要会话变量，但不打算创建或修改它们，则将 Page 指令中的EnableSesSe 属性设置为 ReadOnly。还可以禁用 XML Web servi方法的会话状态。有

58、关信息，请参见使用ASP.NET 和 XML Web servi客户端创建的 XML Web servi。若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 ses节中将 mode 属性设置为 off。例如:se 配置24. 仔细选择会话状态提供程序ASP.NET 为应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处

59、理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。25. 不使用不必要的 Server ControlASP.net 中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用 Server Control。26. ASP.NET 应用程序性能测试在对 ASP.NET 应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application Strees Tool (W

60、AS)是发布的一个免费测试工具，可以从/上。它可以模拟成百上千个用户同时对 web 应用程序进行请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均 TTLB 等性能汇总。Application Center Test (ACT) 是一个测试工具，附带于 Visual Studio.NET 的企业版中，是正式支持的 web 应用程序测试工具。它能够直观地生成图表结果，功能比WAS 多，但不具备多个客户机同时测试的能力。服务器操作系统管理工具中的性能计数器，可以对服务器进行监测以了解应用程序性能。结论对于开发来说，在编写 ASP.NET 应用程序时注意性能问题，养成良好的