asp.net|性能|优化
衡量Web性能的方法



l         衡量web服务器性能的唯一方式是对服务器进行压力测试（stress testing）



1.        自动压力测试工具是衡量的唯一方式



2.        浏览器的点击刷新并不能作为痕量手段……




 


l         收集多个典型应用场景方案：



1.        在应用车工女婿执行过程中模拟典型事物处理的过程



2.        痕量常用的单个页面的性能（热点）



3.        确定个场景及个页面的使用率




 


l         通过测试找出系统的新能指标：



1.        服务器的处理能力



2.        确定适合可接受TTFB/TTLB响应时间范围的可支持的最大客户端负载（并发用户）




 



 


性能测试工具



l         微软Web Application Stress Tool



1.        可免费下载（10MB），适用于XP、2000、2003



2.        http://www.microsoft.com/technet/treeview/default.aspx?url=/technet/itsolutions/intranet/downloads/webstres.asp




 


l         微软应用程序中心测试工具（Microsoft Application Center Test）



1.        作为VS.NET Enterprise 的一部分提供给客户



2.        启用更丰富的脚本及报告




 



 


主要的性能测试观测项PerfMon Counters



l         Processor，CPU % Utilization



Low numbers = blocking or lock contention




 


l         ASP.NET，Requests In Application Queue



出现线型增长时表示服务器已达满负荷




 


l         ASP.NET，Applications，Requests/Sec



动态吞吐量（应保持一致、无大的波动）




 


l         ASP.NET，Applications，Errors Total



预示着功能级错误（应为0）




 


l         ASP.NET App/Worker Process Restarts



表示有严重错误编程级错误（应为0）



压力测试环境的注意事项



l         在独立与Web服务器及应用服务器的机器上运行压力测试工具



1.        否则工具将超出服务器CPU的最大范围



2.        对于繁重的负载使用多个客户端机器




 


l         对测试进行配置，以模拟不同的客户端带宽级别



1.        特定用于衡量56K拨号




 


l         消除应用之外的任何瓶刭：



1.        网络、客户端等




 



 


逻辑设计



l         建议：采用3层逻辑模型



1.        Pages and User Controls UI



2.        Business and Data Access classes in \bin dir



3.        Data withwin a SQL Database via SPROCs




 


l         设计系统时要考虑到Scale-Out的情形



1.        不要假设客户端的请求




 


l         永远会返回到同一机器




 



 


使用最佳的Data Provider



l         ADO.NET 可支持多个Provider:



1.        System.Data.SqlClient



2.        System.Data.OracleClient



3.        System.Data.OleDb



4.        System.Data.Odbc




 


l         所有Provider的编程模型相同



1.        但是性能方面存在明显差异




 


l         建议：使用最佳



1.        在访问MSDE/SQL 是始终使用SqlClient



2.        在访问Oracle时始终使用OracleClient




 



 



 



 


DataReader vs.DataSets



l         DataReader



1.        对查询的结果提供了单向读取的操作



2.        轻量快速-但在Reader关闭之前数据库始终处于连接状态




 


l         DataSet



1.        非连接的数据访问方式



2.        内部使用DataReader用户获取数据



3.        在完成DataSet的获取后会自动关闭DataReader




 


l         Which is better?



1.        依赖于你的应用



2.        原则上在Middle_Tier设计到大量数据处理或进行离线的数据访问时建议使用DataSet




 



 


连接池



l         ADO.NET拥有内置的连接迟



1.        自动缓寸/重新使用连接



2.        不必为此编写任何代码




 


l         代码建议



1.        “在后期打开代码中的连接，然后在早期将其关闭”



2.        切无长时间保持连接状态 – 切无尝试构建你自己的“智能”连接池逻辑



3.        完成后应立即显示地关闭数据库连接，以将其返回致池中




 


l         优化提示：



1.        不同的连接字符串可以生成多个不同的连接池



2.        在Web.Config中存储单个连接字符串



3.        使用ConfigurationSettings.AppSettings以在运行时采用编程形式对其进行访问



4.        观察”.NET CLR数据“性能计数器，以变对由ADP.NET维护的连接池数量保持




 



 


使用存储过程



l         建议将SPROC用于数据存取



1.        通过DBA进行更轻松的性能调试



2.        通过使用数据库事务处理避免出现分布事务成本



3.        有助于防止SQL注入攻击



4.        有助与消除应用与数据库反复调用的成本




 



 



 


服务器控件



l         对性能优化而言有两点需要注意:



1.        ViewState



2.        Number of controls generated(especially for lists)




 



 


ViewState管理



l         ASP.NET controls能够维护页面Control元素的状态:



1.        状态以”viewstate” hidden field进行传递




 


l         负面影响:



1.        增加网络负荷（both on render and postback）



2.        额外的服务器性能消耗（serialize values to/from viewstate）




 


l         ViewState灵活性:



1.        页面级（Can disable viewstate entirely for a page）



2.        控件级（Can disable viewstate usage on a per control basis）




 


l         建议



1.        认真审核该功能的使用



2.        若不使用PostBack功能，在页面级屏蔽ViewState



3.        PostBack时没次都重新生成控件，请对控件级的ViewState屏蔽



4.        使用<% Page Trace=”true”%>跟踪ViewState的大小