.NET Framework部署的性能调整!!!

本页内容

• ASP.NET应用程序和Web服务
• 调整会话状态
• Web应用程序的压力测试工具
• 识别系统瓶颈
• 使用跟踪
• 配置设置
• 构建于.NET Framework之上的其它应用程序
• Internet信息服务
• SQL Server
• 结论

摘要
同先前的ASP程序相比，ASP.NET在性能上提供了极大的改进。虽然ASP.NET的标准配置也可以提供远远超出先前环境的优异性能，但是管理员可能仍然需要对系统配置进行一些调整，以实现最佳的性能表现和伸缩性。本白皮书面向系统管理员，介绍了调校构建于.NET Framework之上的应用程序的性能所需掌握的技术，并且讨论了ASP.NET Web应用程序、ASP.NET Web服务以及.NET远程应用程序。

ASP.NET应用程序和Web服务

与其它类型的应用程序相比，Web程序和Web服务的性能调整工作应当引起更多的重视和注意。这些应用程序一般面向外部用户，而一个糟糕的Web站点肯定会给公司形象造成十分恶劣的影响。和面向企业内部的应用程序不同，定位于外部用户的公众Web服务可能会被数以百万计的用户所访问，而内部应用程序的用户数量则受公司员工规模的限制。

ASP.NET为系统管理员赋予了更多能力，使他们能够对Web程序和Web服务的性能和规模施加更有力的控制。新的会话状态管理能力可以将有关用户访问的信息从应用程序之中完全分离出来，管理员可以选择将信息存储在Web服务器的动态RAM中，存储在状态服务器上，或者是存储在一个数据库中。内置的跟踪功能则允许管理员将性能问题同某段具体的应用程序代码联系起来--决定性地指出问题是由应用程序而不是系统配置问题引起的。

特别针对ASP.NET的新的性能计数器提供了有关应用程序性能的各个细节，为管理员解决系统瓶颈提供了所需的信息。现有的实用工具，例如Microsoft Web Application Stress（WAS）工具可以用来产生站点流量，在真正的用户发现站点存在的问题之前就将这些问题彻底解决。由于ASP.NET既可以用来开发Web程序，也可以用来构建Web服务，管理员可以直接深入到下一代Web商业的内部。本部分的内容将为管理员分析和调整各种ASP.NET应用程序的提供详细的分布指导。

调整会话状态

对Web应用程序和Web服务进行伸缩所需面临的最大挑战之一便是：用户状态是由多个服务器进行维护的。无论Web农场采用何种配置方式，在一个会话中，针对某个用户的请求总是有可能被转发到两个不同的系统上。如果所有的站点内容都是静态的，那么将不会存在任何问题。但是，现在大多数的Web站点都会对用户会话进行跟踪以保存同此用户有关的特定信息，例如喜好、个性化参数和购物车等。

先前版本的ASP允许开发人员访问会话状态信息，并且允许他们将有关用户的信息存储在这个会话对象的内部。这些信息可以从站点的任何一个其它的页面上进行访问。但是，ASP会将这些信息保存在Web服务器的内存之中。因此，如果使用多台Web服务器，用户的请求可能就会被发送到一个与发起会话的服务器不同的其它服务器上，有关会话的信息将无法获得。如果某个Web服务器重新进行了启动，它保存的所有会话信息都将丢失，这对站点的正常运转会造成不可估量的影响--尤其是在您使用该会话保存用户购物车信息的时候。

ASP.NET提供传统的单服务器会话信息，这和ASP的以前版本非常类似。此外，它还为会话信息的集中提供了两个方法，这使得用户可以从Web农场或Web花园的很多不同服务器上获得这些会话数据。具体使用两种方法中的哪一种完全由系统管理员来决定 -- 它并没有以代码形式固定在程序之中。所以，对于那些不是针对Web农场进行设计的ASP .NET Web程序或Web服务，系统管理员可以对其进行衡量和分等。

ASP.NET可以使用三种方法存储会话状态信息：存储在进程中；存储在一台中央状态服务器上；或者存储在SQL Server数据库中。将会话信息保存在进程中这种方法与传统的ASP会话类似，因为会话状态信息也保存在Web服务器的内存之中，不和其它系统进行共享。这种配置方法具有最佳的执行性能，因为ASP.NET不需要同网络中的其它系统通信以取得会话信息。但是，这种做法限制了系统的伸缩性--会话不能跨越多台服务器，而且如果用户从一台Web服务器移动到了另一台服务器上，他们的会话信息将被丢失。

状态服务器是运行一种特殊服务的中央服务器，该服务内置在.NET Framework之中。状态服务器存储状态信息供Web农场中的多台服务器使用。用户可以从一台Web服务器移动到另一台，而不会丢失状态信息。状态服务器引入了一些额外的工作负载，因为在每次用户请求一个页面的时候，会话信息必须能够通过从Web服务器发送到状态服务器的网络请求被检索和被更新。虽然需要花费一些额外工作来处理用户请求，但是系统的伸缩性和可靠性却因此得到了极大的提高，因为Web应用程序可以伸缩到多个多台服务器上。

存储会话状态信息的第三种方法是使用一个SQL Server数据库。这种方法具有与使用中央状态服务器相同的好处 -- 会话可以跨越多台Web服务器进行跟踪。但是，同使用中央状态服务器相比，使用SQL Server服务器跟踪会话产生的工作负载更大。SQL Server服务器能够配置成群集的形式，从而提供最大限度的冗余。此外，SQL Server可以伸缩到配备4颗处理器的高端硬件上，从而实现更多会话的并发存储。

以下部分针对存储会话状态信息的三种不同方法讨论了相应的性能调整措施。所有三种方法可以使用同一套配置参数，并且不会对系统性能造成不良影响。用户可以使用一种“无需Cookie”的方式来管理用户状态，这种方法将状态信息作为URL的一部分，而不是将它们保存在一个Cookie当中。ASP.NET将会话信息插入到给定页面上所有链接的URL之中 --并且仅仅修改相对URL。因此，这种无需Cookie的状态管理不能工作在那些在一个ASP.NET应用程序的内部超链接上使用绝对URL地址的站点上。

调整存储在进程中（In Process）的会话状态。“超时”设置定义了会话状态在用户进行上一次请求后能够存留的时间。默认情况下，该时间被设置为20分钟。所以，如果用户等上20分钟后再向服务器发送一个请求，服务器将创建一个新的会话。该设置不会影响系统，特别是在使用存储在进程中的会话的时候。超时时间定义的越长，在用户不主动访问您的站点期间会话中所存储信息的存活时间也就越长。但是，会话状态在进程中进行维护会占用Web服务器的内存。

如果你的站点用户较少，但是他们的停留时间比较长，或者他们每天都定期多次访问你的站点，那么你可以定义一个较长时间的超时设置。如果你的站点有成千上万的用户，而且这些用户一般仅仅浏览一两个页面就离开，那么你可以设置一个较短时间的超时设置。然后，请仔细监视Web服务器的运行情况，以确定对会话状态的维护是否会对系统性能造成不良影响。

为了调整超时设置，请监视“ASP.NET应用程序”对象中的“活动会话”（Sessions Active）计数器。该计数器指出了当前活动会话的数目，一般来说，该数目会随着超时时间的增加而增多。Web服务器所能够处理的最大会话数量随存储在会话中的信息应用程序数量不同而发生变化。但是，保有过多的并发会话将消耗大量的服务器内存。因此，你还应该监视服务器的内存使用情况。如果在提高了会话的超时时间设置之后，内存的分页操作也随之增加了，那么你应该减少会话的超时时间，或者在服务器上增加更多的内存。能够对内存的分页操作进行较好表述的计数器是“内存”对象中的“每秒读取页面的次数”（Page Reads/sec）计数器。

会话状态选择在machine.config或者web.config文件中定义。默认情况下，小节在machine.config文件中被定义为 “InProc”，这样可以为运行在单台Web服务器上的Web应用程序提供最佳的性能。machine.config中的默认设置为：

<sessionState 
     mode="InProc" 
     stateConnectionString="tcpip=127.0.0.1:42424"
     stateNetworkTimeout="10" 
     sqlConnectionString="data source=127.0.0.1;user id=sa;password=" 
     cookieless="false" 
     timeout="20"/>

使用状态服务器时的会话状态配置。当你使用一台状态服务器管理会话状态的时候， 可以通过stateNetworkTimeout配置设置超时时间，时间单位为秒，ASP.NET Web应用程序将等待状态服务器对网络请求做出响应。默认情况下，此时间被设为10秒钟。有几种原因会导致状态服务器在10秒钟内不能做出响应--状态服务器过载，Web服务器过载，或者状态服务器处于离线状态。如果状态服务器或者Web服务器上的流量很高（接近100%的处理器利用率），并且会话状态对于ASP.NET应用程序非常重要，你可以将此超时时间提高到20秒钟。

通常，在和状态服务器取得联系之前，ASP.NET应用程序不会将用户请求的Web页面发送给用户。所以，如果状态服务器没有响应，最终用户可能必须等到网络超时之后才会接收到一条错误信息。提高stateNetworkTimeout的值可以降低流量高峰期时发生错误的次数；但是，在获知状态服务器离线之前，它会增加用户被迫等待的时间。如果你的Web和状态服务器的超时时间得到了正确配置，你的应用程序应该可以对会话状态错误进行妥善的处理。如果你的用户在看到一个页面之前没有等待10秒钟的耐心，你可以将stateNetworkTimeout从10秒钟减少到5秒钟。如果你的Web和状态服务器经常以近乎100%的CPU利用率运行，并且会话状态信息对于你的ASP.NET Web应用程序很重要，你可以将stateNetworkTimeout提高到20秒。

状态服务器的性能监视可以使用状态服务器上的“性能”（Performance）控制台和“事件查看器”（Event Viewer）。您可以使用“性能”控制台对“ASP.NET”对象中的“活动的状态服务器会话”（State Server Sessions Active）计数器加以监视。此外，您还可以监视处理器的利用率--既包括整体利用率（“处理器”对象中的“% Processor Time”计数器，也包括每个会话状态的利用率（“进程”对象中“% Processor Time”计数器内的aspnet_state.ex实例） 。如果处理器利用率达到了100%，Web服务器将对接收到的会话状态信息请求进行排队，从而损害Web站点的性能。如果状态服务器变得非常忙，以至于发生请求超时现象而不能提供状态信息，将发生ID号从1072到1076的错误事件，这些事件会被记录在状态服务器的应用程序事件（Application Event）日志中。为了解决上述问题，您可以对状态服务器上的处理器进行升级。

为了让ASP.NET Web应用程序能够使用中央状态服务，您可以在应用程序的web.config文件中的小节中加入以下信息。请特别注意stateConnectionString元素，它定义了状态服务器的IP地址和端口号--您应该根据您自己状态服务器的实际情况修改这些属性。sqlConnectionString属性不是一个必需的属性，因为该设置仅仅在使用SQL Server存储会话状态信息时才发挥作用。

<sessionState 
     mode="StateServer" 
     stateConnectionString="tcpip=StateServerIP:42424"
     stateNetworkTimeout="10" 
     cookieless="false" 
     timeout="20"/>

使用SQL Server时的会话状态配置。Web农场的会话状态可以使用一台SQL Server服务器进行管理，如果会话状态信息的重要性足以使您考虑使用冗余服务器，那么使用SQL Server是您最佳的选择。ASP.NET State Service（状态服务）不能进行冗余配置--只能使用单台状态服务器，所以如果该状态服务器发生故障变得不可用，ASP.NET Web应用程序将无法跟踪用户会话。对这台SQL Server服务器的性能监视同其它SQL Server服务器一样。有关SQL Server性能监视方面的更多信息，请参阅Microsoft Press出版的《SQL Server 2000 性能调整技术指南》一书。

说明：如果您决定使用SQL Server数据库来保存会话状态信息，您应该按照本文“SQL Profiler和Index Tuning Wizard”一节中的介绍对ASPState数据库进行调整。

为了让某个ASP.NET Web应用程序使用SQL Server数据库存储状态信息，请将以下信息添加到该程序的web.config文件的 小节当中。您必需修改sqlConnectionString参数，使其符合标准的连接字符串格式，此外，您至少需要提供一个SQL Server的名称或者IP地址，以及一个合法的用户名和口令。为了改善系统的安全性，您应该在SQL Server上创建一个具有最小权限的账户，而不是使用SA账户完成这一切。

<sessionState 
     mode="SqlServer" 
     sqlConnectionString="data source=SQLServerIP;user id=Username;
password=Password" 
     stateNetworkTimeout="10" 
     cookieless="false" 
     timeout="20"/>

Web应用程序的压力测试工具

Microsoft WAS工具是Microsoft 发布的一个免费工具，可以在Web服务器上产生流量负载。该工具可以模拟数百个或数千个用户同时对您的站点进行的访问，然后生成一个带有性能信息的汇总报告。通过在Web服务器上施加额外负载并监视其性能的变化，你可以确定如何对应用程序进行伸缩，以及哪些资源会对系统的伸缩性造成限制。WAS工具可以从以下地址免费下载： http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en. 本节内容将介绍使用WAS工具为ASP.NET页面的呈现建立一个基准和加载测试用ASP.NET Web服务的具体方法。如需获得使用WAS工具的更详细指导，请参阅：http://msdn.microsoft.com/library/en-us/dnduwon/html/d5wast_2.asp.

WAS可以用来测试任何类型的Web服务器。测试ASP.NET Web程序和测试其它Web程序没有什么太大的不同--但是系统管理员在调整ASP.NET程序的性能时应该对WAS报告中的几个关键部分加以特别的重视。WAS报告中的“页面摘要”（Page Summary）部分列出了测试期间被请求的所有页面、页面被请求的次数、传送首字节的时间（Time To First Byte ，TTFB）和传送末字节的时间（Time To Last Byte，TTLB）。TTFB指标可以用来断定Web服务器提交一个ASP.NET页面所需花费的时间。为了获得该时间，您可以：

1. 在ASP.NET Web服务器所在局域网中的一台计算机上安装WAS。
2. 创建一个WAS脚本，该脚本可以对站点上您希望测量的所有.ASPX页面进行查询。
3. 选择脚本设置，然后将“压力级别”（Stress Level）和“压力倍数”（Stress Multiplier）设置为1，如图1所示。这将迫使WAS使用单个客户端请求所有页面，以确保不会同时请求多个页面。

图1 将WAS配置为只使用一个客户端是创建ASP.NET Web程序性能基准测试的一种优秀方法。

4. 接下来，在“测试时间”（Test Run Time）下，将时间值设定为5分钟。这样可以获得一个数量合理的取样点数目。
5. 在“暂停”（Suspend）下，将“预热”（Warmup）时间设定为1分钟，以确保在您开始测量之前每个页面均被请求了数次。ASP.NET页面在初次请求时需要进行编译--因此，第一次获得所请求页面的时间特别长，您不应该使用这些时间来建立性能基准。预热期还会产生各种缓存，这些缓存将在以后的时间发挥效力。
6. 点击工具栏“运行脚本”（Run Script）按钮。脚本将被执行。
7. 在脚本完成之后，请点击“报告”（Reports）选项卡，然后选择新的报告。向下滚动内容直到“页面摘要”（Page Summary）部分，如图2所示。每个页面的TTFB数值是以毫秒为单位的时间值，在轻负载的情况下，您的ASP.NET应用程序需要花费这些时间为用户提交页面。

图2 TTFB Average指标指出了提交ASP.NET页面所需花费的时间。

在轻负载情况下测量TTFB可以建立一个基准。将轻负载下的TTFB值与重负载情况下的TTFB值相比较，您便可以了解到应该如何对Web应用程序进行伸缩，以及这种伸缩将会对最终用户的Web体验产生何种影响。如果TTFB值高于1000毫秒（即1秒钟），在正常流量情况下，产生ASP.NET页面所需的时间便有可能对用户的浏览体验产生影响。通过升级Web服务器的处理器、调整数据库访问方式以及采取本文介绍的其它方法，这个时间可以被降低。

在你打开WAS报告的时候，请注意该报告的“结果代码”（Result Codes）部分。唯一应该被列出的结果代码是“200”--表明所有的请求都已经成功完成。随后，当你在更高的负载下运行此测试的时候，你将可以看到一些错误，这表明该ASP.NET已经到达了它的能力上限。为了提高服务器的工作负载，你可以选择“设置”（Settings），然后增加“压力级别”（Stress Level）和“压力倍数”（Stress Multiplier）的数值。你可以逐步提高这些设置，并且将得到的结果同第一次测试得到的基准结果进行对比，了解站点性能是如何随着流量增加而变慢的。应用程序瓶颈的识别方法，请遵照本文“识别系统瓶颈”部分中的指导进行操作。

WAS还可以用来测试ASP.NET Web服务。默认情况下，当浏览器请求一个.ASMX文件时，ASP.NET Web服务会生成一个可视的页面。用户可以在表单域中输入信息，然后请求会被调用的Web服务进行处理。这些自动生成的页面使用HttpGet Web服务协议，该协议是ASP.NET Web服务默认使用的协议。WAS可以使用该接口模拟由多个并发客户端发出的Web服务请求，如图3所示。针对现有的Web服务生成WAS脚本的最容易方法是使用WAS记录你在浏览器中手动输入的这些请求，然后删除请求路径中的“？”字符后面不包括参数的任何步骤。如果你的Web服务客户端使用了HttpSoap方法，结果将不是一种完美的模拟。但是，对于识别性能瓶颈来说，它仍然不失为一种有用的手段。

图3 通过创建一个脚本，利用合适的参数发出对.ASMX文件的请求，WAS可以对使用HTTPGet方法的Web服务进行测试。

识别系统瓶颈

无论您是采用Microsoft WAS工具来人为地产生一些流量，或者是已经拥有了一个繁忙的站点，对负载情况下Web服务器的性能进行监视均是很重要的。监视服务器资源利用率的最佳工具是性能控制台。在Windows 2000中，您可以点击“开始”按钮、将鼠标指向“程序”，选择“管理工具”，然后点击“性能”，以启动该控制台。在Windows Server 2003中，您可以点击“开始”按钮，指向“所有程序”，选择“管理工具”，然后点击“性能”。表1给出了识别ASP.NET应用程序瓶颈所需的最重要性能计数器。

表1 识别系统瓶颈所用到的性能计数器

对象	计数器	描述
处理器	% 利用率百分比	本指标指出了Web服务器上处理器的总体利用率。处理器是ASP.NET Web服务器上最为常见的瓶颈所在。如果当Web处理负载时该计数器的峰值数值接近100% ，您就应该添加“进程”对象中的“% Processor Time”计数器，以确定出究竟是哪一个进程拖累了服务器的性能。
进程	% 处理器时间百分比	本计数器提供的信息与“% CPU Utilization”计数器类似，但是它可以识别出具体是哪一个进程耗用了大部分的CPU时间。为了确保能够收集到所需的全部信息，您应该在添加该计数器时，选中“添加计数器”（Add Counters）对话框中的“所有实例”（All Instances）单选按钮。如果aspnet_wp 进程占用了大部分处理器时间，这就清楚地说明了ASP.NET页面的呈现是系统的瓶颈所在。如果inetinfo进程出现问题，说明是IIS引起的问题。这些问题可以通过升级Web服务器的CPU、增加多个CPU或者添加更多Web服务器得到解决。如果你的ASP.NET应用程序是由数据库驱动的，并且你在相同系统上运行一个Microsoft SQL Server，你很可能会发现名为sqlservr的进程是引起CPU瓶颈的罪魁祸首。对这种情况的最佳补救方法便是将SQL Server移动到另一台服务器上。或者，升级处理器或者增添更多的处理器也有助于改善这种情况。
ASP.NET应用程序	每秒的请求数	本计数器可以测量ASP.NET请求的接收速度，对于在过载情况下测量Web应用程序的峰值处理能力来说，它也是一种有用的手段。该计数器只会报告针对特定文件的请求数目，这些传递给ASP.NET的文件的扩展名在IIS中进行配置，大多数情况下，它们是一些.ASPX和.ASMX文件。为了查看总的请求数，包括对图像文件的请求，您可以使用“Web服务”对象中的“Get Requests/sec”计数器代替本计数器。
ASP.NET应用程序	活动会话的数目	此计数器用来测量当前处于活动状态的ASP.NET会话的数目。会话是在新的用户发出第一次请求时由ASP.NET程序建立的。会话一直存活，直到：1) 当用户退出登录时，程序明确地放弃了该会话，或者2)在会话超时时间内没有从用户处接收到任何请求。默认情况下，ASP.NET的会话将在20分钟后超时。用户可以修改web.config或machine.config文件中元素的sessionState属性来调整该设置。有关会话和超时时间设置的更多信息，请参看本文的“调整会话状态”一节。
ASP.NET	队列中请求的数目	本计数器指出了当呈现一个页面所需的时间超过了所接受的两个客户端请求之间的时间间隔之后，在队列中进行排队的请求数目。在正常的Web流量下，用户发出请求的速度是不确定的，在最繁忙的时刻，几秒钟内就会发生排队现象。这使得提交页面的时间临时性地增加了，但是在接下来的空闲时段，队列又会很快被消除。负载测试工具（例如WAS）产生的流量一般比较稳定，所以可能引起ASP.NET的“Requests Queued”计数器持续攀升，尽管在实际的应用情境之中，这种情况可能并不会出现。为了模拟这些随机出现的流量高峰和低谷，您可以在WAS的“脚本设置”页中选中“使用随机延迟”（Use Random Delay）复选框。如果在启用了该设置之后，该计数器的数值仍然继续增加，说明该服务器当前的工作负载已经超出了它的能力范围，它将成为一个系统瓶颈，您应该在继续测试之前解决这个瓶颈问题。默认情况下，ASP.NET的队列长度最大可以容纳100个请求。您可以修改web.config或machine.config文件中httpRunTime元素的appRequestQueueLimit属性来改变这一限制。
ASP.NET	被拒绝的请求数	在ASP.NET请求队列被充满之后，新的请求将被拒绝。对于极高负载的情况，这种处理方法对于ASP.NET一般都是正确的，因为它会立即向用户返回一个错误，并且从Web服务器的队列之中删除该请求，而不是强迫用户等待，直到浏览器超时。对本计数器进行监视可以获知在队列长度达到最大之后，Web服务器所接受到请求总数是多少。

使用跟踪

ASP.NET Web程序和Web服务能够对请求和响应进行强有力的跟踪。虽然跟踪工具面向开发人员，主要是为他们解决程序错误和优化程序性能提供的，但是它也可以被系统管理员用来向开发人员提供有关程序性能的特定反馈意见。启用跟踪会增加系统的性能负载，并且可能会暴露一些私人信息，所以只有在对一个程序进行主动分析时，才应该启用跟踪。为了启用程序跟踪，您可以在该程序的web.config文件的小节中添加或者编译如下一些元素：

<trace
     enabled="true"
     requestLimit="10"
     pageOutput="false"
     traceMode="SortByTime"
     localOnly="true"
/>

必须进行修改的关键属性是enabled=”true”。如果您直接连接到Web服务器的桌面，请设置localOnly=”true”属性。该设置确保了远程用户不能访问有关应程序的细节信息。您也可以通过使用localOnly=”false”设置让远程系统能够查看跟踪信息，但是这样做具有一些潜在的安全风险，可能会把跟踪信息暴露给外界。pageOutput=”false” 设置是针对生产用服务器的唯一安全设置；但是，你可以在开发服务器上使用pageOutput=”true” 设置，以在每一个ASP.NET页面的底部查看跟踪信息。requestLimit=”10” 的默认设置规定了只有同前10个ASP.NET请求有关的信息会被存储。如果需要，你可以提高此数值；但是，这样做会增加跟踪工作的工作量。

在对某个程序进行跟踪的时候，你可以从一个应用程序的根目录那里请求一个特殊的页面，即trace.axd。为了在Web服务器上的浏览器中查看该页面，您可以打开如下URL地址： http://localhost/trace.axd。你会看到一个主跟踪页面，如图4所示。请注意：trace.axd文件实际上并没有真的存在于应用程序的根目录下--该请求被ASP.NET截取了，并且进行了动态处理。

 

图4 应用程序跟踪是深入应用程序逻辑，揭开性能瓶颈根源的有用方法。

当你点击请求的“查看详细信息”（View Details）连接时，你将会看到“请求详细信息”（Request Details）页面。该页面提供了有关ASP.NET页面组成和它的底层组件的非常详尽的信息。在“跟踪信息”（Trace Information）部分，如图5所示，展示了页面呈现的每个阶段所需花费的时间。应用程序开发人员还可以在此部分中插入特定于应用程序的信息，以允许管理员发现开发人员代码中存在的性能问题。在跟踪信息部分，请检查“From Last(s)”列以确定完成哪一个阶段需要花费的时间最长。

说明：默认情况下，ASP.NET Web程序（.ASPX文件）会产生很多有用的跟踪信息。管理员还可以跟踪ASP.NET Web服务（.ASMX文件），但是除非开发人员在Web服务中明确地整合进了跟踪能力，否则“Trace Information”和“Control Tree”（控件树）部分将是一片空白。

 

图5 “请求详细信息”的“跟踪信息”部分使得管理员能够将问题原因缩小到某个特定的页面上。

“请求详细信息”页面的下一个部分是“控件树”（Control Tree），如图6所示。控件树列出了页面调用的每一个控件的名称、类型、控件生成的HTML字符数量以及viewstate的字节大小。ASP.NET页面一般由不同的控件组成。一个ASP.NET控件可以是一个表格、一个超链接、一个工具栏或者能够包括在Web页面中的其它任何东西。

 

图6 “控件树”展示了给定页面上每个控件的细节。

Viewstate是一个插入到HTML之中的隐藏字段，ASP.NET用它来跟踪页面的当前设置。程序开发人员经常在不需要它的控件上启用viewstate，这会造成页面产生不必要的臃肿，而控件树则有助于解决这些问题。在控件树的下方，“请求详细信息”页面显示了同页面和请求有关的每一件事情。这些信息对于解决程序错误和分析性能问题十分有用。

说明：在完成所有工作之后，不要忘记在元素中设置enabled=”false”属性。

配置设置

系统管理员能够对ASP.NET程序施加强有力的控制。决定应用程序性能的很多方面都可以通过machine.config和web.config文件进行配置。有关ASP.NET配置的一般性信息，请参阅http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q307626&. 在本节之中，我们将介绍三种可以极大影响ASP.NET性能的配置设置：调试、进程模型以及数据源配置。

禁用调试。ASP.NET包括了一个特殊的调试模式，来帮助开发人员解决程序中存在的问题。调试模式会增加系统负载，并降低系统的整体性能，在投入实际生产应用的ASP.NET Web服务上，应该禁用调试模式。调试模式在machine.config文件的部分中开放的标签中设置，可以通过将该小节添加到web.config文件中取代此设置。在禁用调试模式以后，开放的“compilation”标签应该包括debug=”false”元素，并且可能包含其它非相关的元素，如下所示：

<compilation debug="false" explicit="true" 
defaultLanguage="vb"> 

配置进程模型。如果ASP.NET运行在Windows 2000环境下的IIS 5.0 Server上，machine.config文件的部分中的元素可以包含几个有用的配置设置。在Windows Server 2003和IIS 6.0中，这些项目可以通过Internet信息服务（IIS）的管理工具进行配置。简而言之，ASP.NET进程模型可以自动回收利用应用程序，收回丢失的内存和资源。此外，它能够将ASP.NET被限制到一个多处理器系统中的某几个特定处理器上。大多数的管理员不需要为了优化系统性能而修改machine.config文件中的这一部分。此部分包括了大部分可用于性能调整的有用配置属性。

说明：machine.config文件中的大多数元素都可以通过在web.config文件中放置元素内容而被取代。默认情况下， 元素可以仅仅在machine.config文件中定义。

的默认设置如下：

<processModel 
     enable="true" 
     timeout="Infinite" 
     idleTimeout="Infinite" 
     shutdownTimeout="0:00:05" 
     requestLimit="Infinite" 
     requestQueueLimit="5000" 
     restartQueueLimit="10" 
     memoryLimit="60" 
     webGarden="false" 
     cpuMask="0xffffffff" 
     userName="machine" 
     password="AutoGenerate" 
     logLevel="Errors" 
     clientConnectedCheck="0:00:05"
     comAuthenticationLevel="Connect"
     comImpersonationLevel="Impersonate"
     responseRestartDeadlockInterval="00:09:00"
     responseDeadlockInterval="00:03:00"
     maxWorkerThreads="25" 
     maxIoThreads="25"/>

表2 属性

属性名称	默认设置	描述
cpuMask	0xffffffff。本设置会导致ASP.NET为Web服务器上的每一颗处理器启动一个单独的ASP.NET进程。	用来将ASP.NET限制到多处理器系统中的某些特定处理器上。只有在webGarden属性设置为“false”之后，该属性才会起作用。如果ASP.NET和SQL Server运行在同一个系统上，并且SQL Server使用了相反的cpuMask设置，设置本属性可能会改善系统的性能表现为了计算出需要的cpuMask值，您可以使用附件中的计算器，并且将其设置为科学模式。然后选择二进制计算模式，为ASP.NET将要使用的每一颗处理器输入一个“1”。为每一颗不会被用到的处理器输入一个“0”。然后，将这个数字转换成16进制，并且据此修改machine.config文件中的本元素值。请确信你输入的数字是以 ‘0x’ 开头的，以表明你输入的是一个16进制的数。
webGarden	false	本设置会导致ASP.NET使用cpuMask属性来识别应该为ASP.NET使用哪些处理器。如果将本属性设置为“true”，ASP.NET将使用Windows操作系统自身的调度机制。
requestQueueLimit	5000	如果ASP.NET接受请求的速度大于它响应请求的速度，那么，这些请求将进入队列排队，直到有空闲的处理能力对它们进行处理为止。如果队列的增长超过了特定的规模，ASP.NET将使用一个“服务器过于繁忙”的错误响应用户的请求。根据应用程序的不同，发送这样的一个错误可能要比强迫用户等待服务器响应要好很多。
serverErrorMessageFile	没有设定- 交由ASP.NET进行动态处理	如果发生一个错误，文件的绝对路径将会发送给用户，例如，在requestQueueLimit属性达到设定值的时候。管理员应该使用本设置为用户提供友好的错误信息，通知他们发生了什么问题，并且提醒他们在稍候的时间再次进行尝试。

配置数据源。 某些应用程序允许管理员定义数据源。如果一个ASP.NET程序既可以使用OLEDB数据源，也可以使用固有的SQL数据源，那么您应该尽可能地使用SQL数据源。与使用在ODBC数据源管理器中进行配置的数据源名称（DSN）相比，使用ASP.NET内置的SQL客户端可以将系统性能提高50%之多。不幸的是，在指示应用程序应该以何种方式访问数据方面，目前还没有一种连续一致方法可供使用，所以，请参考该应用程序的文档。

构建于.NET Framework之上的其它应用程序

专为ASP.NET基础结构设计的应用程序为系统管理员调整程序性能赋予了更多的控制能力。但是，还有很多应用程序不使用ASP.NET。例如，.NET 远程Web服务便没有利用ASP.NET，因此，如果希望分析这些应用程序的性能表现，监视ASP.NET性能计数器并不是一个好的办法。此外，.NET远程应用程序不支持HttpGet Web服务协议，所以也不能使用WAS为这些程序产生负载。事实上，对于.NET远程程序，系统管理员必须依靠程序开发人员才能完成大量的性能分析和调整工作。但是，通用语言运行时（Common Language Runtime，CLR）却提供了几个有用的性能计数器，如表3所示。 表3 CLR提供的性能计数器

对象	计数器	描述
.NET CLR Remoting	Remote Calls/sec	用来测量接收远程请求的当前速度。本计数器使得管理员能够精确地测量出应用程序的当前负载。
Process	% Processor Time	该计数器可以测量某个特定进程消耗的处理器百分比。每一个.NET远程程序都有一个唯一的进程名称，该名称同程序可执行文件的名称相匹配。对“Remote Calls/sec”计数器和“% Processor Time”计数器进行监视可以帮助系统管理员更好地理解每个远程调用所需花费的处理时间。
.NET CLR Networking	Bytes Sent, Bytes Received	“Bytes Sent”和“Bytes Received”计数器可以测量由所有的.NET CLR应用程序产生的网络流量，这对于测量程序产生的流量大小很有帮助。它并不包括ASP.NET Web应用程序和Web服务产生的流量。
.NET CLR LocksAndThreads	Total # of Contentions, Current Queue Length	运行在CLR中的所有应用程序所发生争用的数目。对于健康的应用程序，发生系统资源的争用是一件正常的事情。但是，如果在发生间歇性的性能问题期间，该数字保持上升，就说明某个关键的系统资源被某一个程序锁定了。这可能是某个应用程序低效使用系统资源的标志，可以由程序开发人员来纠正这一问题。
.NET CLR Data	SqlClient: Current # pool and nonpooled connections	测量.NET程序的活动SQL连接的数目，包括ASP.NET程序。

Internet信息服务

IIS是ASP.NET Web程序、ASP.NET Web服务和很多.NET远程程序的重要组成部分。理解IIS性能调整的重要性是实现高性能.NET程序的关键。对IIS进行的调整并不仅仅针对ASP.NET一家，而且已经有大量的相关文档可供学习。因此，这一部分的内容不是本文的讲述重点。有关IIS性能调整的更详细信息，请阅读题为“利用IIS5.0对Web服务器进行性能调整的艺术和科学”的白皮书，该白皮书可从以下地址获得。http://www.microsoft.com/windows2000/techinfo/administration/web/tuning.asp.

SQL Server

构建于.NET Framework之上的大部分应用程序都连接到SQL Server上检索数据。在很多情况下，数据库或者数据库连接会成为程序的性能瓶颈。对于由数据驱动的程序，理解SQL Server的性能问题对程序整体性能的调整有着不言而喻的重要意义。程序开发人员对使用何种方法从SQL Server数据库中取得数据有着很大的发言权，而他们所做出的选择对程序的整体性能有着极其重要的影响。虽然程序进行的某个特定查询一般不能由系统管理员进行修改，但是你可以分析一个.NET程序对数据库所发出请求的类型，并且据此对索引方式加以调整。本节内容将给出有关SQL Server索引调整的一个详细的分布指导-- 一种可能会迅速提高程序性能的方法。有关SQL Server性能的详细信息，请阅读Microsoft Press出版发行的SQL Server 2000性能调整技术指南一书。

改善SQL Server性能的一种容易方法是结合使用索引调整向导（Index Tuning Wizard）和SQL Profiler。Profiler可以记录SQL Server接收到的查询，并且将它们记录在一个文件或者数据库的一个表中。索引调整向导能够分析这些文件，找出应该对数据库设计进行的修改，以改善数据库性能，同时允许系统管理员选择最为适合的修改方式。这些工具的运行会增加数据库的工作负载，所以您不应该在负荷已经接近最大处理能力的生产系统中运行这些工具。为了使用Profiler和Index Tuning Wizard优化您的数据库设计，您应该：

1. 登录到SQL Server的控制台中。
2. 点击“开始”按钮，指向“程序”，指向“Microsoft SQL Server”，然后点击“Profiler”。
3. 打开“文件”菜单，点击“新建”，选择“跟踪”，以创建一个新的跟踪。
4. 在“连接到SQL Server”对话框中，选择您的SQL Server和身份验证方法，然后点击“确定”。
5. 在“跟踪属性”对话框中，从模板名称下拉列表中选择“SQLProfilerTuning”。选中“保存到文件”复选框，然后在“另存为”对话框中输入一个新的文件名。点击“保存”。
6. 点击“运行”按钮开始记录发送给SQL Server的请求，如图7所示。如果你的程序当前处于活动状态，请让优化器运行足够长的时间，以便至少能够收集到100行的数据。如果您的程序当前没有在运行，请以一种最为典型的方式启动该程序以产生数据请求。

 

图7 Profiler收集SQL请求供Index Tuning Wizard分析使用。

7. 在收集到足够的请求之后，点击工具栏上的“停止”按钮。从“工具”菜单中，选择“Index Tuning Wizard”（索引调整向导）。该向导将出现，如图8所示。点击“下一步”按钮，然后在接到提示时选择你的数据库服务器。

 

图8 Index Tuning Wizard分析由Profiler产生的工作负载文件，并且对如何修改索引以改善性能提出建议。

8. 在Index Tuning Wizard页中，从“数据库”列表中选择应用程序最常使用的数据库。如果你的应用程序需要同一个以上的数据库展开通信，你应该在每一个数据库上重复上述过程。然后点击“下一步”按钮。
9. 在“指定工作负载”页中，选择“我的工作负载文件”（My Workload File）单选按钮。在“打开”对话框中，选择你在步骤5中指定的文件。点击“打开”按钮，然后点击“下一步”。
10. 在“选择需要调整的数据表”（Select Tables To Tune）页上，点击“选择所有数据库”（Select All Tables）按钮。点击“下一步”。此时，Index Tuning Wizard将试着找出现有索引存在的问题以及解决办法，以改善数据库性能。这个过程将持续数分钟。
11. 在完成分析之后，你将看见“索引建议”（Index Recommendations）页。如果Index Tuning Wizard找到了可以改善性能的方法，它将把这些方法在本页面中罗列出来，并且对可能产生的性能改进做出评估。一般来说，你可以安全地接受这些修改。点击“下一步”继续。
12. 在“完成索引调整向导”（Completing the Index Tuning Wizard）页上，点击“完成”按钮关闭向导，然后在收到提示时点击“确定”按钮。另外，你可能还需要关闭SQL Profiler。

结论

系统管理员可以对以.NET Framework.为基础构建的程序性能进行深入的剖析和控制。例如， ASP.NET便具有会话状态跟踪能力，可以对每个应用程序进行单独跟踪。这些功能使得管理员可以调整一个应用程序的工作，使其满足他们的工作环境对性能、伸缩性和可靠性的独特需要。本白皮书介绍了监视.NET Framework程序性能、模拟繁忙条件和配置主要性能参数的方法。如果希望获得更多有关程序性能调整的信息，请访问以下地址： http://msdn.microsoft.com/library/en-us/dnduwon/html/d5dplyover.asp.