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

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

先介绍一下场景:公司某网站产品的一个页面加载速度非常慢,完全加载完成大约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的请求时间:

      图片1

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

     三、查看IIS的相关配置。

     结果:动态压缩,静态压缩都已经启用。

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

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

     以后会上LogStash,然后升级IIS(IIS6用起来真蛋疼)。

    四、观察浏览器响应时间

   3

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

     4

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

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

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

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

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

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

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

      那个代码不适合,然后改造 ,最后修改后的代码:

     图片4

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

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

版权声明:本文为zw369原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/zw369/p/4640757.html