本来想写一个网站优化的系列（前端到后端的数据库,垂直优化到分布式,后面会补上），但没有时间（借口），今天就总结一下前几天优化网站的过程。

网站优化重点在于找出出现性能问题的地方，往往是解决方案很简单，过程很艰辛。

先介绍一下场景：公司某网站产品的一个页面加载速度非常慢，完全加载完成大约8秒左右，要尽可能的提高网站加载速度。

线上环境：IIS6.0 +ASP.NET MVC4

解决思路：

对于网站优化我曾经总结过一套方法论：顺着HTTP请求方向追一排查，例如：浏览器->IIS服务器->ASP.NET->数据库。根据二八原则，其中几个阶段的20%的代码造成了80%的性能问题，所以我要重点寻找那20%的代码。但方法论始终是方法论，根据我对业务判断，我的排查流程就变成了这样 : 数据库->ASP.NET->IIS服务器->浏览器。(后来结果证明，我应该按照方法论走)

优化过程：

一、用SQL Profiler监控慢SQL

用SQL Profiler把Duration在3000毫秒以上的慢SQL赛选出来，结果一条也没有，缩小Duration到2000毫秒。结果没有。继续观察有没有N+1的问题，也没有。

二、查看是否是ASP.NET应用程序的问题：

用HttpModule监控每个URL的请求时间：

结果当前请求的URL非常快。进行下一步

  三、查看IIS的相关配置。

结果：动态压缩，静态压缩都已经启用。

开始分析IIS日志，IIS日志中记录了每个请求的执行时间，这个时间和HttpModule的时间相减就是网络传输时间，由此可以判断是否是网络引起的问题。

理想总是好的，结果IIS日志已经十几G了，要挨个分析不知道啥时候，放弃，进行下一步。

以后会上LogStash，然后升级IIS（IIS6用起来真蛋疼）。

四、观察浏览器响应时间

由上图接收时间可以看出：网站响应时间大部分都浪费到了网络下载。而且页面大小为1.7M。难道是网络延时太大？ping一下

以上说明网络没有太大延时。这时候突然想起来了公司的网络限速了，下载速度平均200kb/s , 那么1.7M网页下载时间也就大约8s左右了。

再查看1.7M网页内容全是html，而且响应报文头里没有Contend-Ecoding ,说明没进行压缩。但明明服务器开启了动态压缩。

这时想起了博客园写的一篇文章：迁入阿里云后：解决了一个IIS动态内容压缩的问题 但IIS6下没有这个节点，需要修改metabase.xml，修改metabase.xml会影响所有网站，网站出现问题，风险太大，我们需要做的只是压缩当前网站的动态内容,想其他方案。

五、自己写HttpModule解决压缩问题

开始想造* : 在EndRequest用Gizp压缩然后输出，结果EndRequest始终拿不到响应内容。

在万能的*找到这两篇文章 Can I detect if content has been compressed in my HttpModule?

Use .Net 2.0 compression library and HttpModule to compress your webpages

那个代码不适合，然后改造 ，最后修改后的代码：

上线以后经过测试，该页面响应速度2s以内了，而且响应报文头里面也有了Content-Encoding：gzip

总结，其实一开始我应查看浏览器的响应时间这些信息，但根据以往的优化经验和现在的业务，我把关注点放在了后端，不过以后我会按照我的方法论走，那样解决问题的成本更低。