(摘自中国软件)
| NET Framework部署的性能调整 白皮书 Tony Northrup 本页内容
摘要 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文件中定义。默认情况下， <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文件中的 <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文件的 <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 将WAS配置为只使用一个客户端是创建ASP.NET Web程序性能基准测试的一种优秀方法。
图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 识别系统瓶颈所用到的性能计数器
使用跟踪 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，这会造成页面产生不必要的臃肿，而控件树则有助于解决这些问题。在控件树的下方，“请求详细信息”页面显示了同页面和请求有关的每一件事情。这些信息对于解决程序错误和分析性能问题十分有用。 说明：在完成所有工作之后，不要忘记在
配置设置 系统管理员能够对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文件的 <compilation debug="false" explicit="true" defaultLanguage="vb"> 配置进程模型。如果ASP.NET运行在Windows
2000环境下的IIS 5.0 Server上，machine.config文件的 说明：machine.config文件中的大多数元素都可以通过在web.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 属性
配置数据源。 某些应用程序允许管理员定义数据源。如果一个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提供的性能计数器
Internet信息服务 IIS是ASP.NET Web程序、ASP.NET Web服务和很多.NET远程程序的重要组成部分。理解IIS性能调整的重要性是实现高性能.NET程序的关键。对IIS进行的调整并不仅仅针对ASP.NET一家，而且已经有大量的相关文档可供学习。因此，这一部分的内容不是本文的讲述重点。有关IIS性能调整的更详细信息，请阅读题为“利用IIS5.0对Web服务器进行性能调整的艺术和科学”的白皮书，该白皮书可从以下地址获得。
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优化您的数据库设计，您应该：
图7 Profiler收集SQL请求供Index Tuning Wizard分析使用。
图8 Index Tuning Wizard分析由Profiler产生的工作负载文件，并且对如何修改索引以改善性能提出建议。
结论 系统管理员可以对以.NET Framework.为基础构建的程序性能进行深入的剖析和控制。例如， ASP.NET便具有会话状态跟踪能力，可以对每个应用程序进行单独跟踪。这些功能使得管理员可以调整一个应用程序的工作，使其满足他们的工作环境对性能、伸缩性和可靠性的独特需要。本白皮书介绍了监视.NET Framework程序性能、模拟繁忙条件和配置主要性能参数的方法。如果希望获得更多有关程序性能调整的信息，请访问以下地址： http://msdn.microsoft.com/library/en-us/dnduwon/html/d5dplyover.asp.
|
