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

原文：http://dev.rdxx.com/NET/Framework/2003-3/23/103704650_4.shtml

在轻负载情况下测量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.