使用Microsoft Web Application Stress Tool对web进行压力测试

使用MicrosoftWebAppIicationStressTool对web进行压力

测试

你的Web服务器和应用到底能够支持多少并发用户访问？在出现大量并发请求的情况

下，软件会出现问题吗？这些问题靠通常的测试手段是无法解答的。本文介绍了Microsoft

为这个目的而提供的免费工具WAS及其用法。另外，本文介绍了一种Web应用的性能优

化方法，并利用WAS测试了它的性能改善程度。

随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也

成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出

性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。

本文介绍Microsoft的WebApplicationStressTool（WAS,Web应用负载测试工具）

在Web服务器性能测试中的应用（注：Stress基本含义为“重压；压力”等，本文称之为“负

载”）。另外，我们还将通过WAS评估一种相对简单的网站性能改善方法，这种方法的基

本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。

负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用

户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型

的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。

无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未

来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组织也可以时

它们的网站进行负载测试，因为Microsoft的WAS是可以免费下载的。WAS要求Windows

NT4.0SP4或者更高，或者Windows2000。为了对网站进行负载测试，WAS可以通过一

台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies,也能够模

拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。如果

你对WAS和Microsoft的另外一个测试工具WebCapacityAnalysisTool（WCAT）之间

的差别感兴趣，可以访问MicrosoftWeb工具的比较页面。

要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法

之创建脚本：通过记录浏览器的活动；通过导入HS日志；通过把WAS指向Web网站

的内容；或者手工制作。图1所显示的是通过记录浏览器事件生成的脚本的一部分，网站

是Microsoft的DuwamishBookStore»Duwamish是Microsoft开发的电子商务Web应用

示例，从Duwamish网站的“Phase4”链接可以下载这个软件包。卜一载包中包含了它自己的

WAS测试脚本。

彳产Wc，，Appimatton5la«*ag\PfogiMniFWi

File£&SonpUViewWindow

riairi^

DefeUH

SampleScriptServo|Ind2a

Ul»ra_pe<f

NoimBto^J

DtAM4fTVSh

ContentItee

Settr»g5

fillP«ifCouni«ft

手PageGroups

Doublv-cbck«r»avcv。itemtoviewd，3.

<?Ue

6ClMr^t

0Cookies

UMre(_db«<reTt

UKr«_pu&hup

Scripts:D“WIE..

【图1】

制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如

果你已经有•个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户

点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。

图1这个脚本中我们假定有30个会员在浏览书店，同时又有一个会员正在购买。要

模拟两者混合而成的行为，首先必须创建页面组并在脚本的PageGroup分枝确定点击分布

情况。在PageGroup分枝中我们可以增加、修改或删除页面组，也可以为各个组修改流量

的分布。

图2显示了grp_browse和grp_buy这两个页面组以及30比1的流量分布

:WWebApplicationStress-GAProgramFiles\MicrosoftWebA叩licdtionStressTo

瞥FileEditScriptsViewWindowHelp■1x|

闺誉|@叫噢|廿|0X|封圄闿U

固

：wDefaults

由

：警SampleScript

@.:-警Ultra.perf

日

.等Duwamish

.

.恒ContentTree

啕Sellings

IsilPerfCounters

PageGroups

.Users

噢Clients

,Cookies

Illh^rlhTra代d

警Scripts：Duwam..

图2】

创建了页面组之后，我们就可以在主脚本视图中赋予各个请求不同的页面组，如图3

所示。为每个请求指定页面组相当于告诉WAS如何分布流量。记住在本例中对grp_buy组

页面的请求约占总数的3%,而对grp_browse组页面的请求约占97%。

【图3】

如果需要在查询字符串中传递“名字-值”对，可以用WAS的查询字符串编辑器来定义各

个变量的所有可能的值。在输入变量值后，既可以要求WAS顺序地使用变量的各个值，

也可以要求WAS在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实

性，也可以帮助避免缓冲对测试结果的影响准备好测试脚本之后，我们可以调整测试配置

以便观察不同条件下的应用性能。图4是WAS的设置界面

掾?WebApplicationStress-G:\ProgramFilesKMiciosoKWebApplicationStres…

瞥FileEditScriptsViewWindowHelp■|t91x|

包警|Ql|电I砌I|x|到图置

0-:Defaults

国

.ConcurrentConnections

由SampleScript

：Ukra_perfStresslevel(threads):I50^

0-

Duwamish

ContentT隧Stressmultiplier(socketsperthread):|1

Settings

PerfCounUTestRunTime

PageGroup

的

UsersDays:|0Hrs:|0Mins:|Sec:|0

Clients

Cookies

.RequestDelay(inmilliseconds)

固

Ultra_db$Ues$

…

「Userandomdelay|5000

®:-Ultra_pushup

®.-

@-ws51

NewRecordedSuspend

Warmup:Hrs:|0Mins:|FSec:|0

Cooldown:Hrs:|0Mins:|TSec:|0

Bandwith

厂Throttlebandwidth□

Redirects

gFollowHTTPredirectsMax:|15

Throughput

底Useusers,passwords,andsavecookies

厂Savepagestatistics

r~Resolvenetworklookupsonremoteclients

4—I」

警Scripts：Duwam..

【图4】

StressLevel和Stressmultiplier这二个项决定了访问服务器的并发连接的数量。

Microsoft建议不要选择超过100的StressLevel值。如果要模拟的并发连接数量超过100个,

可以调整Stressmultiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客

户机协调。有关在测试中使用多个客户机的更多信息，参见

/kb/hkb13.htrrio

如果网站提供个性化服务，要进行身份验证或使用Cookies,我们还要为WAS提供一

个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的

Cookies„增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发

连接的要求(StesssLevel乘以StressMultiplier)。

WAS允许设置warmup(热身)时间，一般可以设置为1分钟。在warmup期间WAS

开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机

会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结

果。

设置页面提供的另外一个有用的功能是限制带宽(throttlebandwidth)。带宽限制功

能能够为测试模拟出Modem(14.kK,28.8K,56K),ISDN(64K,128K)以及T1(1.54

M)的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问

Web服务器所感受的性能。

要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。

使用WAS,从远程WindowsNT和Windows2000机器获取和分析性能计数器(Performance

Counter)是很方便的。加入计数器要用到图5所示的PerfCounters分枝。

*WebApplicationStress-G:\ProgramFilesXMicrosoftWebApplicationSt，.

辔FileEditScriptsViewWindowHelp-|g|x|

闺警|国|日噢I睁kIx|LUU

®:-Defaults

®:-

CollectionInterval:AddCounter

ls:-SampleScript

B-Ultra_perf

WBITMASKV^ctiveServerPage式RequestExecutionTime

DuwamishWBITMASKXActiveServerPage$\RequestWaitTime

花|ContentTreeWBITMASKXActiveServerPage八RequestsQueued

曲Settings\\BITMASK\ActiveServerPage$\Reque$ts/Sec

PerfCounters\\BITMASK\ProcessorLTProcessorTime

5PdgeGroups

.Users

啜Clients

3Cookies

Ultra_dbstress

Ultra_pushup

ws$1

NewRecordedScript

铲Scripts：Duwam..

【图5】

在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离

出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。

■处理器：CPU使用百分比(%CPUUtilization)

•线程：每秒的上下文切换次数(ContextSwitchesPerSecond(Total))

•ASP：每秒请求数量(RequestsPerSecond)

-ASP：请求执行时间(RequestExecutionTime)

-ASP：请求等待时间(RequestWaitTime)

-ASP：置入队列的请求数量(RequestsQueued)

CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于

处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于

每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测

项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待

时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增

加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发

用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应

时间则会增加。要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的

临界点非常重要。

置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个

COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了

一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地

超过75%,说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。

在这种情况下，测试客户机的数量必须增加，或者减小测试的StressLevel。

每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可

以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。

如果这是一个新创建的测试脚本，你应该检查一下报表的ResultCodes部分。这部分

内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404

代码(页面没有找到)，说明在脚本中有错误的页面请求。

页面摘要部分提供了页面的名字，接收到第一个字节的平均时间(TTFB),接收到最

后一个字节的平均时间(TTLB),以及测试脚本中各个页面的命中次数。TTFB和TTLB

这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求

到接收到应答数据第-个字节的时间总和(以毫秒计),TTLB包含了TTFB,它是客户机

接收到页面最后一个字节所需要的累计时间。

报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同

时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍

的内容。为了给你一个有关表所提供信息种类的印象，图6摘录了一个报表实例。

<、WebApplicationStiett-G:\ProQfamFilot\MiciosoftWebApplicationStie««TooAWAS.mdb[RepofU),1□!x|

QReEdiScnpUViewWindowHelp

p|产IQHMI||M赞I

.©=>ageGroupsFageResults

:*30©Data

URI:_GETzd4_3/xnlcatasp?l

PGET/d<3/HitCount12

pGET/d4_giaphct/$p^

?GET/d4_gtaphics/tabResultCodes

?GET/d4_gtaph»csAabCodeDescriptionCount

PGET/d4_gfophcx/ms«200OK12

pGET/D4_Graphicj/d4

3GET/msdn_ie4-Timeto(fxrstbyte(inmi11iseconds)

GET/d4_araphcs/d4t

?GET/d4_3/catx$lAverage

Min:

pGET/d4_3/xnlcatasp25thPercentlie

pGETAM_3/cMxtl50thPercentil©

PGET/d4_3/xmlcat7SthPercen11le

?GET/d<3/c^tx$l」Max209360

PGET/d4_3/xmlcataspTimetolastbyte(inmi11iseconds)

GET/d4_3/c«txsl

PGET/d4_3/xmlcotaspAverage7S383

pGETZd4_3/c«txslMin52489

1□GETZd43/xmldetacjzJ25thPercentile53434

14

皆ScriptsQReports|

【图6】

随着Internet应用的11益广泛，用户的要求和期望也在不断地发展。今天的客户期待

个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本低廉。对于能够

适应用户需求不断变动的可定制页面来说，静态HTML已经退出了舞介，比如内容根据客

户请求变化的页面就是其中一例。这一切都要求系统保存相关的数据，例如有关用户本身

以及用户可能请求哪些信息的数据。

紧跟这些趋势的Web开发者已经开始提供可定制的Web网站。象搜索数据之类的任

务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多

网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。

我们可以使用以下几种方法来解决这些问题：

1.优化ASP代码。

2.优化数据库调用。

3.使用存储过程。

4.调整服务器性能。

优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都

会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问

网站的用户进行数据库调用。

这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容

依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预先从数据库提

取信息写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不

断变化的数据库数据，必须有一个调度程序管理静态页面的生成。

当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提

取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。

为了保证能够在合适的时间更新静态HTML页面，把下面的代码加入到相应的ASP页面前

面：

随着Internet应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性

化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本低廉。对于能够适应

用户需求不断变动的可定制页面来说，静态HTML已经退出了舞台，比如内容根据客户请

求变化的页面就是其中一例。这一切都要求系统保存相关的数据，例如有关用户本身以及

用户可能请求哪些信息的数据。

紧跟这些趋势的Web开发者已经开始提供可定制的Web网站。象搜索数据之类的任

务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多

网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。

我们可以使用以下几种方法来解决这些问题：

1.优化ASP代码。

2.优化数据库调用。

3.使用存储过程。

4.调整服务器性能。

优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都

会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问

网站的用户进行数据库调用。

这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容

依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预先从数据库提

取信息写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不

断变化的数据库数据，必须有一个调度程序管理静态页面的生成。

当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提

取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。

为了保证能够在合适的时间更新静态HTML页面，把下面的代码加入到相应的ASP页面前

面：

<%

Iastllpdated=AppIication("LastUpdated")

present!ime=now

ifDATEDIFFCh''IastUpdated.oresentTime)>=1then

AppIicationCLastUpdated")=presentTime

response.redirect

("PATHTRANSLATED")

endif

K>

<htmI>

Staticcontentgoeshere

</htmI>

每当该页面被调用，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之

间的差值大于预定的数值，Update.asp脚本就会运行；否则，该ASP页面把余下的HTML

代码发送给浏览器。

最后更新时间从Application变量得到，它的第一次初始化由global.asa完成。具体的

更新时间间隔应根据页面内容的更新要求调整。

如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，

这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。

如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数

据的变化，我们可以在ASP页面中调用Update脚本。这样，每当数据库内容改变时服务

器上也有了最新的静态HTML页面。

另种处理频繁变动数据的办法是借助MicrosftSQLServer7.0的Web助手向导(Web

AssistantWizard),这个向导能够利用Transact-SQL、存储过程等从SQLServer数据生

成标准的HTML文件。

利用SQLServer任务，Web助手向导能够用来定期地生成HTML页面。正如前面概

要介绍的方案，Web助手可以通过触发子更新HTML页面，比如在指定的时间执行更新或

者在数据库数据变化时执行更新。

SQLServer使用名为sp_makewebtask的存储过程创建HTML页面，它的参数是目

标HTML文件的名字和待执行存储过程的名字，查询的输出发送到HTML页面。另外，也

可以选择使用可供结果数据插入的模板文件。从前面的代码可以看出，当ASP页面

HtmIMain.asp需要更新时,控制以ASP文件的物理路径为参数转到了Update贞血。Update

脚本的任务是用新的HTML数据刷新发出调用的ASP文件，并把调度ASP代码加入到文

件的开头。为此，Update脚本打开调度模板文件，拷贝调度ASP代码，然后控制转到了

另一部分脚本，这部分脚本主要任务是执行数据库操作。Update用路径参数以写模式打开

HtmIMain.asp文件，数据库操作的输出以HTML格式写入这个文件。

万一用户访问页面的时候正好在执行更新，我们可以利用锁或者其他类似的机制把页面

延迟几秒钟。HtmIMain.asp(纯HTML加调度ASP代码)和main.asp(普通的ASP文

件)在WAS卜进行了性能测试。main.asp文件要查找5个不同的表为页面提取数据。为

了和这两个文件相比较，一个只访问单个表的ASP页面(SingleTableTest.asp)和一个纯

HTML文件(PlainHtml.html)也进行强试.测试结果如?所示：

平均TTLB

文件名字命中数平均TTFB(ms)

(ms)

PlainHtml.html847474

SingleTableTest.asp868.88789.38

Main,asp9125.893759.56

HtmlMain.asp9149.891739.89

其中TTFB是指TotalTimetoFirstByte,TTLB是指TotalTimetoLastByte。

这些测试在一台WindowsNTWorkstation4.0SP6运行PersonalWebServer的机器

上实施。为了使性能指标更明显，带宽限制到了14.4K。在实际环境中数值变化可能很大,

但这个结果精确地反映了各个页面在性能上的差异。

测试结果显示访问单个表的ASP页面的处理时间是720.5ms,而纯HTML文件则为

427ms。Main.asp和HtmIMain.asp的输出时间相同，但它们的处理时间分别为3633.67ms

和1590ms。也就是说，在这个测试环境下我们可以把处理速度提高43%。

如果我们要让页面每隔•定的访问次数更新，比如100次，那么这第100个用户就必须等

待新的HTML页面生成。不过，这个代价或许不算太高，其他99个用户获得了好处。

静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须

要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调

用的页面，而且这种情况下它将发挥出更大的效率。

在大多数情况F，动态页面的生成将在相当大的程度上提高网站的性能而且无需在功能

匕有所折衷。虽然有许多大的网站采用了这个策略来改善性能，也有许多网站完全由于进行

大量没有必要的数据库调用而表现出很差的性能。

Microsoft的WAS是一个功能非常丰富的服务器性能测试工具，可以帮助我们准确地判

断什么方案将适合于提升网站性能；是否某个方案(比如本文第二部分的静态页面方案)能

够显著地改善性能。

本文对WAS的介绍应当说是相当粗略和肤浅的。WAS还提供了一个对象模型，我们可

以通过脚本扩展它的功能。T^H/?ObjModel/default.htmnJ

以看到一个脚本示例。这个脚本将登记Web服务器的每秒最大请求数量，自动地增加Stress

Level值直到服务器处理器利用率达到90%为止。

WAS能够为你提供有关ASP应用和它所运行的硬件的丰富的信息。在WAS上花费一些

时间，你就能够更深入地了解你的应用的性能、稳定性、瓶颈和局限性。花费这种时间是值

得的。

posted@2008-10-1414:04liuhaitao阅读(125)|评论(0)|编辑

ASP.NET性能优化

转：http://wangwblogs.com/archive/2006/06/05/417632.html

1.数据库访问性能优化

数据库的连接和关闭

访问数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数

据库交换信息以通过身份验证，比较耗费服务器资源。ASP.NET中提供了连接池

(ConnectionPool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在

连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。

连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响

性能•因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，

从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。

使用存储过程

存储过程是存储在服务器上的一组预编译的SQL语句，类似于DOS系统中的批处理

文件。存储过程具有对数据库立即访问的功能，信息处理极为迅速。使用存储过程可以避免

对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调

用缓存中的二进制代码即可。

另外，存储过程在服务器端运行，独立于ASP.NET程序，便于修改，最重要的是它可

以减少数据库操作语句在网络中的传输。

优化查询语句

ASP.NET中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源

的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句

中包含子查询语句，充分利用索引等。

2.字符串操作性能优化

使用值类型的ToString方法

在连接字符串时，经常使用"+”号直接将数字添加到字符串中。这种方法虽然简单，也

可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱操作转化为引用类

型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托

管堆中分配一个新的对象，原有的值复制到新创建的对象中。

使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。

运用StringBuilder类

String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个

String对象并将新值赋予该对象，其方法ToString对性能的提高并非很显著。

在处理字符串时，最好使用StringBuilder＞类，其.NET命名空间是System.Text。该类

并非创建新的对象，而是通过Append,Remove,Insert等方法直接对字符串进行操作，

通过ToString方法返回操作结果。

其定义及操作语句如下所示：

intnum;

System.Text.StringBuilderstr=newSystem.Text.StringBuilder();〃创建字符串

str.Append(num.ToString());〃添力口数值num

Response.Write（str.ToString）;〃显示操作结果

3.优化Web服务器计算机和特定应用程序的配置文件以符合您的特定需要

默认情况下，ASP.NET配置被设置成启用最广泛的功能并尽量适应最常见的方案。因

此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提

高应用程序的性能。下面的列表是您应该考虑的一些选项。

仅对需要的应用程序启用身份验证。默认情况下，身份验证模式为Windows,或集成

NTLMo大多数情况下，对于需要身份验证的应用程序，最好在Machine.config文件中禁

用身份验证，并在Web.config文件中启用身份验证。

根据适当的请求和响应编码设置来配置应用程序。ASP.NET默认编码格式为UTF-8。

如果您的应用程序为严格的ASCII,请配置应用程序使用ASCII以获得稍许的性能提高。

考虑对应用程序禁用AutoEventWireupo在Machine.config文件中将

AutoEventWireup属性设置为false,意味着页面不将方法名与事件进行匹配和将两者挂钩

（例如Page_Load）。如果页面开发人员要使用这些事件，需要在基类中重写这些方法（例

如，需要为页面加载事件重写Page.OnLoad,而不是使用Page_Load方法）。如果禁用

AutoEventWireup,页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性

能提升。

从请求处理管线中移除不用的模块。默认情况下，服务器计算机的Machine.config文

件中＜httpModules＞节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以

从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需

要自定义它。

例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从＜httpModules＞列

表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进入和离开代

码。

4.一定要禁用调试模式

在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调

试模式，应用程序的性能可能受到非常大的影响。

5.对于广泛依赖外部资源的应用程序，请考虑在多处理器计算机上启用网络园艺

ASP.NET进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程

（每个CPU一个），并且每个进程都将处理器关系设置为其CPUo此技术称为网络园艺。

如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的COM对象（这里只是提

及两种可能性），则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之

前，您应该测试应用程序在网络园中的执行情况。

6.只要可能，就缓存数据和页输出

ASP.NET提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数

据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求（特别是在站点中

预期将有较大通讯量的区域），可以优化这些页的性能。与.NETFramework的任何Web

窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。

使用ASP.NET缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有

开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项

分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代

码清除和垃圾回收工作。若关心此问题，请监视与ASP.NETApplications性能对象关联的

CacheTotalTurnoverRate性能计数器。高周转率可能说明存在问题，特别是当项在到期

前被移除时。这也称作内存压力。

7.选择适合页面或应用程序的数据查看机制

根据您选择在Web窗体页显示数据的方式，在便利和性能之间常常存在着重要的权

衡。例如，DataGridWeb服务器控件可能是一种显示数据的方便快捷的方法，但就性能而

言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的HTML自己呈现数据

可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。RepeaterWeb服务

器控件是便利和性能的折衷。它高效、可自定义且可编程。

8.将SqlDataReader类用于快速只进数据游标

SqlDataReader类提供了一种读取从SQLServer数据库检索的只进数据流的方法。

如果当创建ASP.NET应用程序时出现允许您使用它的情况，则SqlDataReader类提供

比DataSet类更高的性能。情况之所以这样，是因为SqlDataReader•使用SQLServer

的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader类实现

Enumerable接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见

SqlDataReader类。有关ASP.NET如何访问数据的信息，请参见通过ASP.NET访问数

据。

9.将SQLServer存储过程用于数据访问

在.NETFramework提供的所有数据访问方法中，基于SQLServer的数据访问是生

成高性能、可缩放Web应用程序的推荐选择。使用托管SQLServer提供程序时，可通

过使用编译的存储过程而不是特殊查询获得额外的性能提高。

10.避免单线程单元(STA)COM组件

默认情况下，ASP.NET不允许任何STACOM组件在页面内运行。若要运行它们，

必须在.aspx文件内将ASPCompat=true属性包含在@Page指令中。这样就将执行用

的线程池切换到STA线程池，而且使HttpContext和其他内置对象可用于COM对象。

前者也是一种性能优化，因为它避免了将多线程单元(MTA)封送到STA线程的任何调

用。

使用STACOM组件可能大大损害性能，应尽量避免。若必须使用STACOM组件,

如在任何interop方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多

的信息。另外，小心不要在构造页面期间创建任何STACOM组件。例如下面的代码中，

在页面构造时将实例化由某个线程创建的MySTAComponent,而该线程并不是将运行页面

的STA线程。这可能对性能有不利影响，因为要构造页面就必须完成MTA和STA线程

之间的封送处理。

<%@PageLanguage="VB"ASPCompat="true"%>

<scriptrunat=server>

DimmyCompasnewMySTAComponent()

PublicSubPage_Load()

myComp.Name="Bob"

EndSub

</script>

<html>

<%

Response.Write(myComp.SayHello)

%>

</html>

首选机制是推迟对象的创建，直到以后在STA线程下执行上述代码，如下面的例子所

示。

<%@PageLanguage="VB"ASPCompat="true"%>

<scriptrunat=server>

DimmyComp

PublicSubPage_Load()

myComp=newMySTAComponent()

myComp.Name="Bob"

EndSub

</script>

<html>

<%

Response.Write(myComp.SayHello)

%>

</html>

推荐的做法是在需要时或者在Page_Load方法中构造任何COM组件和外部资源。

永远不要将任何STACOM组件存储在可以由构造它的线程以外的其他线程访问的共

享资源里。这类资源包括像缓存和会话状态这样的资源。即使STA线程调用STACOM组

件，也只有构造此STACOM组件的线程能够实际为该调用服务，而这要求封送处理对创

建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请

研究一下使COM组件成为MTACOM组件的可能性，或者更好的办法是迁移代码以使

对象成为托管对象。

11.将调用密集型的COM组件迁移到托管代码

.NETFramework提供了一个简单的方法与传统的COM组件进行交互。其优点是可

以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将

组件迁移到托管代码是值得的。每一情况都是不样的，决定是否需要迁移组件的最好方法

是对Web站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何

COM组件迁移到托管代码。

许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移Web应用程序时。

在这种情况下，最大的性能障碍之•是将数据从非托管环境封送到托管环境。因此，在交互

操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例

如，公共语言运行库中的所有字符串都是Unicode的，所以应在调用托管代码之前将组件

中的所有字符串转换成Unicode格式。

另外，-处理完任何COM对■象或本机资源就释放它们。这样，其他请求就能够使用

它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。

12.在VisualBasic.NET或JScript代码中使用早期绑定

以往,开发人员喜欢使用VisualBasic.VBScript和JScript的原因之一就是它们所

谓“无类型，，的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一

个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的

性能。

VisualBasic现在通过使用OptionStrict编译器指令来支持类型安全编程。为了向后

兼容，默认情况下，ASP.NET不启用该选项。但是，为了得到最佳性能，强烈建议在页中

启用该选项。若要启用OptionStrict,请将Strict属性包括在@Page指令中，或者，对

于用户控件，请将该属性包括在@Control指令中。下面的示例演示了如何设置该属性，

并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

<%@PageLanguage="VB"Strict="true"%>

<%

DimB

DimCAsString

'Thiswillcauseacompilererror.

A="Hello"

'Thiswillcauseacompilererror.

B="World"

'Thiswillnotcauseacompilererror.

C="mm"

'Butthiswillcauseacompilererror.

C=0

%>

JScript.NET也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下

面任何一种情况，则变量是晚期绑定的：

被显式声明为Object。

是无类型声明的类的字段。

是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。

最后一个差别比较复杂，因为如果JScript.NET编译器可以根据变量的使用情况推断

出类型，它就会进行优化。在下面的示例中，变量A是早期绑定的，但变量B是晚期绑

定的。

varA;

varB;

A=,,Hellon;

B='World";

B=0;

为了获得最佳的性能，当声明JScript.NET变量时，请为其分配一个类型。例如，var

A:Stringo

13.使请求管线内的所有模块尽可能高效

请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时

快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模

块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。

14.使用HttpServerUtility.Transfer方法在同一应用程序的页面间重定向

采用Server.Transfer语法，在页面中使用该方法可避免不必要的客户端重定向。

15.必要时调整应用程序每个辅助进程的线程数

ASP.NET的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一

个使用足够CPU功率的应用程序，该结构将根据可用于请求的CPU功率，来决定允许

同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。

通过使用与ASP.NETApplications性能对象关联的PipelineInstanceCount性能计数

器，可以在PerfMon中监视线程门控。

当页面调用外部资源，如数据库访问或XMLWebservices请求时，页面请求通常停

止并释放CPUo如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么

这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致Web服务器上存在大量

同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控

因子是外部资源的响应时间，则让过多请求等待资源，对Web服务器的吞吐量并无帮助。

为缓和这种情况，可以通过更改Machine.config配置文件节点的

maxWorkerThreads和maxIOThreads属性，手动设置进程中的线程数限制。

注意辅助线程是用是处理ASP.NET请求的，而10线程则是用于为来自文件、数据

库或XMLWebservices的数据提供服务的。

分配给这些属性的值是进程中每个CPU每类线程的最大数目。对于双处理器计算机,

最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有

四个或八个CPU的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认

值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。

注意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系

统将CPU周期花在维护线程而不是处理请求上。

16.适当地使用公共语言运行库的垃圾回收器和自动内存管理

小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工

作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避

免含Finalize方法的对象，因为它们在后面会导致更多的工作。特别是在Finalize调用中

永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题

经常会对Web服务器环境的性能造成毁灭性的打击，因为在等待Finalize运行时，很容

易耗尽某个特定的资源。

17.如果有大型Web应用程序，可考虑执行预批编译

每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编

译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要

很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给ASP.NET性

能上的好处，因为它将许多页面编译为单个程序集。从己加载的程序集访问一页比每页加载

新的程序集要快。

批