C#性能优化Word格式.docx

C#性能优化Word格式.docx

《C#性能优化Word格式.docx》由会员分享，可在线阅读，更多相关《C#性能优化Word格式.docx（13页珍藏版）》请在冰豆网上搜索。

　　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，或集成NTLM。

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

　　根据适当的请求和响应编码设置来配置应用程序。

ASP.NET默认编码格式为UTF-8。

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

　　考虑对应用程序禁用AutoEventWireup。

在Machine.config文件中将AutoEventWireup属性设置为false，意味着页面不将方法名与事件进行匹配和将两者挂钩（例如Page_Load）。

如果页面开发人员要使用这些事件，需要在基类中重写这些方法（例如，需要为页面加载事件重写Page.OnLoad，而不是使用Page_Load方法）。

如果禁用AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。

　　从请求处理管线中移除不用的模块。

默认情况下，服务器计算机的Machine.config文件中<

httpModules>

节点的所有功能均保留为激活。

根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。

检查每个模块及其功能，并按您的需要自定义它。

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

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

4.一定要禁用调试模式 

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

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

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

　　ASP.NET进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程（每个CPU一个），并且每个进程都将处理器关系设置为其CPU。

此技术称为网络园艺。

如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的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类实现IEnumerable接口，该接口也允许您将数据绑定到服务器控件。

有关更多信息，请参见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线程下执行上述代码，如下面的例子所示。

DimmyComp 

myComp=newMySTAComponent（） 

　　推荐的做法是在需要时或者在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指令中。

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

Strict="

DimB 

DimCAsString 

'

Thiswillcauseacompilererror. 

A="

Hello"

B="

World"

Thiswillnotcauseacompilererror. 

C="

!

"

Butthiswillcauseacompilererror. 

C=0 

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

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

　　被显式声明为Object。

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

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

　　最后一个差别比较复杂，因为如果JScript.NET编译器可以根据变量的使用情况推断出类型，它就会进行优化。

在下面的示例中，变量A是早期绑定的，但变量B是晚期绑定的。

varA;

varB;

;

B=0;

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

例如，varA:

String。

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

　　请求管线内的所有模块在每次请求中都有机会被运行。

因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。

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

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

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

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

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

已知一个使用足够CPU功率的应用程序，该结构将根据可用于请求的CPU功率，来决定允许同时执行的请求数。

这项技术称作线程门控。

但是在某些条件下，线程门控算法不是很有效。

通过使用与ASP.NETApplications性能对象关联的PipelineInstanceCount性能计数器，可以在PerfMon中监视线程门控。

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

如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。

遗憾的是，有时这可能导致Web服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。

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

　　为缓和这种情况，可以通过更改Machine.config配置文件节点的maxWorkerThreads和maxIOThreads属性，手动设置进程中的线程数限制。

　　注意 

辅助线程是用来处理ASP.NET请求的，而IO线程则是用于为来自文件、数据库或XMLWebservices的数据提供服务的。

　　分配给这些属性的值是进程中每个CPU每类线程的最大数目。

对于双处理器计算机，最大数是设置值的两倍。

对于四处理器计算机，最大值是设置值的四倍。

无论如何，对于有四个或八个CPU的计算机，最好更改默认值。

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

进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将CPU周期花在维护线程而不是处理请求上。

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

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

另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含Finalize方法的对象，因为它们在后面会导致更多的工作。

特别是在Finalize调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。

最后这个问题经常会对Web服务器环境的性能造成毁灭性的打击，因为在等待Finalize运行时，很容易耗尽某个特定的资源。

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

　　每当发生对目录的第一次请求时都会执行批编译。

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

如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。

此功能带给ASP.NET性能上的好处，因为它将许多页面编译为单个程序集。

从已加载的程序集访问一页比每页加载新的程序集要快。

　　批编译的缺点在于：

如果服务器接收到许多对尚未编译的页面的请求，那么当Web服务器分析并编译它们时，性能可能较差。

为解决这个问题，可以执行预批编译。

为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。

然后，当用户首次访问您的站点时，页面及其程序集将已被编译。

　　没有简单的机制可以知道批编译何时发生。

需一直等到CPU空闲或者没有更多的编译器进程（例如csc.exe（C#编译器）或vbc.exe（VisualBasic编译器））启动。

　　还应尽量避免更改应用程序的\bin目录中的程序集。

更改页面会导致重新分析和编译该页，而替换\bin目录中的程序集则会导致完全重新批编译该目录。

　　在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。

不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。

经常更改的页面应在它们自己的目录中（每个目录最多几百页）以便快速编译。

　　Web应用程序可以包含许多子目录。

批编译发生在目录级，而不是应用程序级。

18.不要依赖代码中的异常 

　　因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。

如果有可能检测到代码中可能导致异常的状态，请执行这种操作。

不要在处理该状态之前捕获异常本身。

常见的方案包括：

检查null，分配给将分析为数字值的String一个值，或在应用数学运算前检查特定值。

下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。

两者产生相同的结果。

try 

{ 

result=100/num;

} 

catch（Exceptione） 

result=0;

//...tothis. 

if（num!

=0） 

else 

19.使用HttpResponse.Write方法进行字符串串联 

　　该方法提供非常有效的缓冲和连接服务。

但是，如果您正在执行广泛的连接，请使用多个Response.Write调用。

下面示例中显示的技术比用对Response.Write方法的单个调用连接字符串更快。

Response.Write（"

a"

）;

Response.Write（myString）;

b"

Response.Write（myObj.ToString（））;

c"

Response.Write（myString2）;

d"

20.除非有特殊的原因要关闭缓冲，否则使其保持打开 

　　禁用Web窗体页的缓冲会导致大量的性能开销。

21.只在必要时保存服务器控件视图状态 

　　自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值（您不需要编写任何代码）。

但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。

您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。

例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。

在这种情况下，禁用视图状态可以节省处理时间。

　　默认情况下，为所有服务器控件启用视图状态。

若要禁用视图状态，请将控件的EnableViewState属性设置为false，如下面的DataGrid服务器控件示例所示。

asp:

datagridEnableViewState="

false"

datasource="

..."

runat="

server"

/>

　　您还可以使用@Page指令禁用整个页的视图状态。

当您不从页回发到服务器时，这将十分有用：

%@PageEnableViewState="

　　注意@Control指令中也支持