Web应用程序性能调优
1.1 背景介绍
性能考虑必须贯穿在日常的编码中,性能监控要列入QA日常工作,每个程序员都要懂得如何做性能调优。性能往往与程序性能、数据量、浏览器性能负载、服务器负载、网络带宽
等都有关系。
1.2 技术知识点
1.2.1 相关工具
程序性能是否存在问题,必须以实际的监控数据作为参考,包括请求开始时间、持续时长、页面大小、数据量等等。这里介绍几种常用的监控工具。
1.2.1.1 Firebug
Firefox插件,版本V1.2.1,提供对HTML、CSS、脚本、Dom、网络、Cookie等的监控。性能调优主要利用网络选项,监控请求执行的时间;必要时也可以监控HTML、脚本和Cookie。
适用于Firefox环境,监控单次请求页面和单词的Http Web请求,免费。 https://addons.mozilla.org/zh-CN/firefox/addon/1843
1.2.1.2 Http Watch
IE、Firefox插件,版本V6.0.17。V5.x版本只适用于IE。提供对单个Http Web请求的监控,包括其Header、Cookie、Cache、Content等等,其Time Chart提供对发送、等待、接收
三个阶段时长的精确监控。收费,有破解。 http://www.httpwatch.com/
1.2.1.3 Fiddler2
独立程序,版本V2.1.9.4 Beta,提供对所有IE发出的Http Web请求的监控,包括Header、Content、Time Line、Catch等。适用于需要对Http Web请求和响应内容的详细监控。免
费,基于.NET构建,需要安装.NET Framework。http://www.fiddler2.com/fiddler2/
1.2.1.4 Pingdom
免费的整站测试工具,其模拟浏览器载入指定页面的所有资源,包括HTM;、CSS、Javascript等所有对象,并在时间轴面板上显示每个对象载入的具体时间。如下图所示。
http://tools.pingdom.com
1.2.1.5 MSSQL Server Profile
MSSQL Server 2005的组成部分,对数据库性能进行监控。通常用于监控是否多次执行特定存储过程,以及特定存储过程执行的时长。这里不赘述。
1.2.1.6 VS Studio Trace
VS Studio Debug工具的一部分,用于在程序中输出相应的调试信息,由此监控特定方法执行的时长;允许在web.config中控制是否输出调试信息。通常搭配trace.axd监控POST请
求。适用于单个页面对每个方法执行时长的监控。
应用程序级别的Trace
<configuration>
<system.web>
<trace enabled="true" requestLimit="40" localOnly="false" pageOutput ="false"/>
</system.web>
</configuration>
单个页面的Trace
请在该页的 @ Page 指令中将 Trace 属性设置为 false。将存储您包括在页代码中的任何 TraceContext.Write 或 TraceContext.Warn 语句,并且它们只返回到跟踪查看器。
如果希望跟踪信息附加到与其关联的页的末尾,请在 Web.config 文件的跟踪配置节中将 pageOutput 属性设置为 true。如果要跟踪信息只显示在跟踪查看器中,则将该属性设置
为 false。如果您启用应用程序级跟踪,但不想显示应用程序某些页的跟踪信息,则使用 @ Page 指令将不想显示 跟踪信息的页的 Trace 属性设置为 false。
通过http://localhost/trace.axd 查看Get和Post的跟踪信息。
1.2.2 调优方向
1.2.2.1 单个请求或方法执行时间特别长
问题描述
由于代码、数据量、存储过程等原因,导致某个请求或者方法执行时间特别长,导致性能瓶颈。比如Order Complete页面(DDN-622,DDN-624),通过UPS实时获取Delivery Date
耗时需要1秒。
如何调优
查看页面代码、特定方法是否有优化的可能性。利用Http Watch监控每个HTTP Web请求,对于在内网执行时间超过100毫秒(页面大小100K以内)特别留意。必要时利用Trace监控
相应页面方法的执行时长,比如Page_Load、相关响应事件等。
1.2.2.2 页面数据量特别大
问题描述
由于页面数据量特别大,在数据量获取(Server一级)、浏览器呈现可能会导致性能。通过Http Watch监控发送、等待、接收的时长。判定是否违反“只取所需”的原则导致数据
冗余。比如,Order Complete页面加载需要600毫秒以上(DDN-613),由于加载Order信息时将Shipping Info、Payment Info也一并加载进来,造成在数据库级别的数据冗余和时
间浪费。
如何调优
只取所需,减少数据冗余。
1.2.2.3 页面特别大
问题描述
由于所需呈现的数据量特别大,造成HTML页面特别大,浏览器解析呈现缓慢,造成性能瓶颈。比如Bom的Component Usage、Insertion & Guarantee ,由于矩阵数据造成页面容量
超过2M、4M。
如何调优
使用更加紧凑的HTML,减少HTML嵌套,不再使用.NET默认的校验器,减少页面容量;限制不必要的ViewStage。
1.2.2.4 Javascript性能瓶颈
问题描述
浏览器对Javascript的执行性能差异造成此瓶颈,特别是当页面比较大的时候,IE的执行效率只有Firefox、 Safari的60%左右。比如document.getElementById()可能造成性能瓶
颈。
如何调优
用JQuery的API替代普通的Javascirpt API,在Javascript一级缓存数组。
1.2.2.5 存储过程性能瓶颈
问题描述
数据库一级未做优化,比如主键、索引,导致查询效率低下;存储过程使用了效率低下的语句,比如IN查询、临时表、实时统计、动态查询、游标循环等,造成执行效率低下。
如何调优
建立主键、索引,使用效率更高的执行语句;用统计表替代实时统计。参照:080319DatabaseCapability的培训记录。当数据量比较小的时候,通过定义表变量而不是临时表处理
。
1.2.2.6 减少HTTP请求次数
问题描述
在Javascript循环中通过Ajax多次发起HTTP请求;页面中内嵌多个IFRAME;页面频繁刷新或者重载。
如何调优
不在循环中发起HTTP请求;适当的数据和页面缓存;减少内嵌IFRAME的使用。避免页面频繁刷新。
1.2.2.7 避免多次调用数据库
问题描述
在方法循环中多次调用业务类访问数据库,比如For each、Data Bind、Date Item Bound。MSSSQL Server Profile能监控到此类操作。
如何调优
避免多次调用数据库,如确实需要查询,在数据量少的情况下,将数据缓存在内存并在缓存中查询。
1.2.3 调优步骤
结合Http Watch、Firebug确认每个页面请求的执行时长,凭经验判定是否存在性能瓶颈。
在页面适当位置添加trace信息,确认哪些方法比较费时。
代码审查,查找存在问题的代码、存储过程、脚本。
确认每次查询的数据量和预期结果,过滤冗余数据。
调优后,程序性能须有数量级上的改善。
1.2.4 代码规范
严格执行公司的代码规范,特别是命名、存储过程规范。
每次代码提交之前,利用SVN DIFF工具确认每个代码修改,确认无误后再提交。
每一个分出去的Issue,导师、PM、Team Leader必须做到代码审查。
不重复制造轮子,注意代码封装和复用,不制造冗余代码。
对Cookie、Session集中管理,KEY要管理起来;不再使用的代码、方法要及时删除。
1.3 项目实践
1.3.1 监控每个页面的执行时长
利用Firebug、Http Watch、Filddler2、Pingdom分别监控可疑页面的执行时长,判断可能导致页面性能低下的代码块。
1.3.2 监控Profile
对可疑代码进行代码审查,如果怀疑是由于存储过程等原因导致的数据库性能低下,结合MSSQL Server Profile监控可疑存储过程或者表结构。
1.3.3 Trace监控方法执行的时长
对可疑代码进行代码审查,如果怀疑是由于C#代码导致的页面性能低下,结合VS Studio Trace监控代码段的执行时长。
1.4 参考资料
《高性能网站建设指南》
http://www.cnblogs.com/JeffreyZhao/category/82418.html
http://www.cnblogs.com/FrameWork/archive/2006/10/16/529835.html
http://www.cnblogs.com/FrameWork/archive/2006/10/16/530827.html
1.5 学习建议
养成良好的编码习惯
避免常见的编码误区
柳德才
13691193654
18942949207
QQ:422157370
liudecai_zan@126.com湖北-武汉-江夏-庙山