浅谈asp.net程序优化技巧(3)_.Net教程

推荐：如何在GridView数据源为空时也显示表头
首先，需要GridView的AutoGenerateColumn属性为false。 进行正常的绑定后，添加页面事件 this.PreRender+=OnPagePreRender; 这个事件只要比绑定晚就可以，不必非得是PreRender。 然后判断如果数据源无数据，就执行以下代码 if (gridView.DataSource is DataTa

       
       22. 避免到服务器的不必要的往返过程
　   虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。
　　通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的 代码。
　　如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。
　　使用 Page.IsPostBack 避免对往返过程执行不必要的处理
　　如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的，使用 Page.IsPostBack 属性有条件地执行代码。例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。

 void Page_Load(Object sender, EventArgs e)
  {
   // Set up a connection and command here.
   if (!Page.IsPostBack)
   {
   String query = "select * from Authors where FirstName like ’%JUSTIN%’";
   myCommand.Fill(ds, "Authors");
   myDataGrid.DataBind();
   }
  } 

　　由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false.如果是，则执行代码。如果该属性设置为 true，则不执行代码。
　　注意如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。

　　23. 当不使用会话状态时禁用它

　　并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。
　　若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false.例如，<%@ Page EnableSessionState="false" %>.
　　注意如果页需要访问会话变量，但不打算创建或修改它们，则将 @ Page 指令中的 EnableSessionState 属性设置为 ReadOnly.
　　还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services.
　　若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off.例如，<sessionstate mode="off" />.

　　24. 仔细选择会话状态提供程序
　　ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 sql Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用 进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参 见 ASP.NET 状态管理。

　　25. 不使用不必要的Server Control
　　ASP.net中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control. 

       26. ASP.NET应用程序性能测试
　　在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：
　　Web Application Strees Tool （WAS）是Microsoft发布的一个免费测试工具，可以从http://webtool.rte.microsoft.com/上下载。它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均TTLB等性能汇总报告。
　Application Center Test （ACT） 是一个测试工具，附带于Visual Studio.NET的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户 机同时测试的能力。
　　现在写一个asp.net的web应用程序变得非常的简单， 许多的程序员都不愿花时间去构建一个性能良好的应用程序。本文将要讨论提高web应用程序性能的十大方法。我将不限于只讨论asp.net应用程序的内 容，因为它们只是web应用程序的一个子集。本文也不能提供一个完整提高web应用程序性能的指南，因为这需要一本书的篇幅。本文只提供一个提高web应 用程序性能的良好的开端。（剩下的只有我们自己慢慢研究了）。
　　在工作这外，我经常去攀岩，在每次攀岩之前，我都会重温一下攀岩线路图及看一下前面的成功的攀岩者的建议。因为我们需要它们的成功经验。同样的，当你需要修改某个有性能问题的程序或者是要开发一个高性能的站点时，你也需要学习怎么样写一个高性能的web应用程序。
　　我个人的经验主要来源于在微软的ASP.NET组担任程序经理，运行和管理www.asp.net网站，和协助开发Community Server（它是ASP.NET Forums，。Text， 和 nGallery的集成升级版本软件）。我想这些经验能我让来帮助大家。
　　你也许会想到把你的应用程序划分成不同的逻辑层。你也可能听过三层物理架构或N层架构，这是最常用的架构模式，它把不同的程序功能物理的分配给 各个硬件来执行。这样，如果我们想提高应用程序的性能的话，加一些硬件就可以达到目的了。按理说这种方法能提高应用程序的性能，但是我们应该避免使用这种 方法。所以，只要有可能，我们都应该把ASP.NET页面和它用到的组件放到一个应用程序中运行。
　　因为分布式的布署，要用到Web Services或者Remoting，它将使应用程序的性能下降20%或者更多。
　　对于数据层有点不同，最好还是把它独立出来布署，用一个单独的硬件来运行它。虽然这样，但是数据库仍然是应用程序性能的瓶颈。因此，当你想优化你的程序的时候，首先想到的地方就应该是优化数据层了。
　　在修改应用程序的出现性能问题的地方之前，你要先确认出问题的地方的程序看起来很严密，性能分析器对于查找应用程序哪些地方花费了多长时间非常有用。这些地方是我们用直觉感觉不到的。
　　本文讨论两种类型的性能优化：一种是大的性能优化（big optimizations），如用ASP.NET的Cache；另一种是小的性能优化（tiny optimizations）。小幅的性能优化有时候非常有用。你只对你的代码作一个小的改到，然后一次调用它一千或一万次。作一次大的性能优化，你会发 生你的应用程序的速度会有一个很大的提升。作一次小的性能优化，也许每次请求只能提高一微秒，但是如果每天的请求量很大的话，那么应用程序就有很显著的性 能提升。

数据层的性能
　　当你要优化一个应用程序的性能的时候，你可以按下面的顺序工作：你的代码要访问数据库？如果要，访问数据库频率怎么样？同样，这种测试方法也可 以用在用 Web Service或。NET Remoting的程序代码中。本文将不讨论用Web Services和Remoting的程序优化的问题。
　　如果在你的代码中有一段必须访问数据库的请求，而你在其它的地方又看到实现同样的功能的代码，那么你首先要优化它。修改和完善继续测试，除非你有一个非常大的性能问题，你的时间最好花在优化查询，连接数据库，返回数据集的大小，以及一次查询往返回的时间上。
　　根据经验的总结，让我们来看看十个能帮助你提升你的应用程序性能的经验，我将按将它们提升效率的多少从大到小小依次说明。

　　一、返回多个数据集
　　检查你的访问数据库的代码，看是否存在着要返回多次的请求。每次往返降低了你的应用程序的每秒能够响应请求的次数。通过在单个数据库请求中返回多个结果集，可以减少与数据库通信的时间，使你的系统具有扩展性，也可以减少数据库服务器响应请求的工作量。
　　如果你是用动态的SQL语句来返回多个数据集，那我建议你用存储过程来替代动态的SQL语句。是否把业务逻辑写到存储过程中，这个有点争议。但 是我认为，把业务逻辑写到存储过程里面可以限制返回结果集的大小，减小网络数据的流量，在逻辑层也不用在过滤数据，这是一个好事情。
　　用SqlCommand对象的ExecuteReader方法返回一个强类型的业务对象，再调用NextResult方法来移动数据集指针来定 位数据集。示例一演示了一个返回多个ArrayList强类型对象的例子。只从数据库中返回你需要的数据可以大大的减小你的服务器所耗用的内存。

　　二、对数据进行分页
　　ASP.NET的DataGrid有一个非常有用的功能：分页。如果DataGrid允许分页，在某一时刻它只下载某一页的数据，另外，它有一个数据分页的浏览导航栏，它让你可以选择浏览某一页，而且每次只下载一页的数据。
　　但是它有一个小小的缺点，就是你必须把所有的数据都绑定到DataGrid中。也就是说，你的数据层必须返回所有的数据，然后 DataGrid再根据当前页过滤出当前页所需要的数据显示出来。如果有一个一万条记录的结果集要用DataGrid进行分页，假设DataGrid每页 只显示25条数据，那就意味着每次请求都有9975条数据都是要丢弃的。每次请求都要返回这么大的数据集，对应用程序的性能影响是非常大的。
　　一个好的解决方案是写一个分页的存储过程，例子2是一个用于对Northwind数据库orders表的分页存储过程。你只需要传当前页码，每页显示的条数两个参数进来，存储过程会返回相应的结果。
　　在服务器端，我专门写了一个分页的控件来处理数据的分页，在这里，我用了第一个方法，在一个存储过程里面返回了两个结果集：数据记录总数和要求的结果集。
　　返回的记录总数取决于要执行查询，例如，一个where条件可以限制返回的结果集的大小。因为在分页界面中必须要根据数据集记录的大小来计算总 的页数，所以必须要返回结果集的记录数。例如，如果一共有1000000条记录，如果用where条件就可以过滤成只返回1000条记录，存储过程的分页 逻辑应该知道返回那些需要显示的数据。

　   三、连接池
　　用TCP来连接你的应用程序与数据库是一件昂贵的事情（很费时的事情），微软的开发者可以通过用连接池来反复的使用数据库的连接。比起每次请求 都用 TCP来连一次数据库，连接池只有在不存在有效的连接时才新建一个TCP连接。当关闭一个连接的时候，它会被放到池中，它仍然会保持与数据库的连接，这样 就可以减少与数据库的TCP连接次数。
　　当然，你要注意那些忘记关的连接，你应在每次用完连接后马上关闭它。我要强调的是：无论什么人说。NET Framework中的GC（垃圾收集器）总会在你用完连接对象后调用连接对象的Close或者Dispose方法显式的关闭你的连接。不要期望CLR会 在你想象的时间内关掉连接，虽然CLR最终都要销毁对象和关闭边接，但是我们并不能确定它到底会在什么时候做这些事情。
　　要用连接池优化，有两条规则，第一，打开连接，处理数据，然后关闭连接。如果你必须在每次请求中多次打开或关闭连接，这好过一直打开一个边接， 然后把它传到各个方法中。第二，用相同的连接字符串（或者用相同的用户标识，当你用集成认证的时候）。如果你没有用相同的连接字符串，如你用基于登录用户 的连接字符串，这将不能利用连接池的优化功能。如果你用的是集成的论证，因为用户很多，所以你也不能充分利用连接池的优化功能。。NET CLR提供了一个数据性能计数器，它在我们需要跟踪程序性能特性的时候非常有用，当然也包括连接池的跟踪了。
　　无论你的应用程序什么时候要连在另一台机子的资源，如数据库，你都应该重点优化你连资源所花的时间，接收和发送数据的时间，以及往返回之间的次数。优化你的应用程序中的每一个处理点（process hop），它是提高你的应用的性能的出发点。
　　应用程序层包含与数据层连接，传送数据到相应的类的实例以及业务处理的逻辑。例如，在Community Server中，要组装一个Forums或者Threads集合，然后应用业务逻辑，如授权，更重要的，这里要完成缓存逻辑。

　　四、 ASP.NET缓存API
　　在写应用程序之前，你要做的第一件事是让应用程序最大化的利用ASP.NET的缓存功能。
　　如果你的组件是要在Asp.net应用程序中运行，你只要把System.Web.dll引用到你的项目中就可以了。然后用HttpRuntime.Cache属性就可访问Cache了（也可以通过Page.Cache或HttpContext.Cache访问）。
　　有以下几条缓存数据的规则。第一，数据可能会被频繁的被使用，这种数据可以缓存。第二，数据的访问频率非常高，或者一个数据的访问频率不高，但 是它的生存周期很长，这样的数据最好也缓存起来。第三是一个常常被忽略的问题，有时候我们缓存了太多数据，通常在一台X86的机子上，如果你要缓存的数据 超过 800M的话，就会出现内存溢出的错误。所以说缓存是有限的。换名话说，你应该估计缓存集的大小，把缓存集的大小限制在10以内，否则它可能会出问题。在 Asp.net中，如果缓存过大的话也会报内存溢出错误，特别是如果缓存大的DataSet对象的时候。
　　这里有几个你必须了解的重要的缓存机制。首先是缓存实现了“最近使用”原则（ a least-recently-used algorithm），当缓存少的时候，它会自动的强制清除那些无用的缓存。其次 “条件依赖”强制清除原则（expiration dependencies），条件可以是时间，关键字和文件。以时间作为条件是最常用的。在asp.net2.0中增加一更强的条件，就是数据库条件。当 数据库中的数据发生变化时，就会强制清除缓存。要更深入的了解数据库条件依赖请看Dino Esposito 在MSDN杂志2004年七月刊的Cutting Edge专栏文章。

分享：揭秘ASP.NET中设置默认提交按钮的代码
publicstaticvoidSetDefEnterControl(System.Web.UI.ControlCtrl) { PagemPage=Ctrl.Page; stringmScript; mScript=@scriptlanguage=javascript; mScript=mScript+functiondocument.onkeydown(){; mScript=mScript+vare=event.srcElement;; mScript