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请求，免费。

1.2.1.2 Http Watch
IE、Firefox插件，版本V6.0.17。V5.x版本只适用于IE。提供对单个Http Web请求的监控，包括其Header、Cookie、Cache、Content等等，其Time Chart提供对发送、等待、接收三个阶段时长的精确监控。收费，有破解。

1.2.1.3 Fiddler2
独立程序，版本V2.1.9.4 Beta，提供对所有IE发出的Http Web请求的监控，包括Header、Content、Time Line、Catch等。适用于需要对Http Web请求和响应内容的详细监控。免费，基于.NET构建，需要安装.NET Framework。

1.2.1.4 Pingdom
免费的整站测试工具，其模拟浏览器载入指定页面的所有资源，包括HTM;、CSS、Javascript等所有对象，并在时间轴面板上显示每个对象载入的具体时间。

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

单个页面的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监控代码段的执行时长。p