你的位置:首页 > 软件开发 > ASP.net > 网站优化实战

网站优化实战

发布时间:2015-07-12 13:00:06
本来想写一个网站优化的系列(前端到后端的数据库,垂直优化到分布式,后面会补上),但没有时间(借口),今天就总结一下前几天优化网站的过程。 网站优化重点在于找出出现性能问题的地方,往往是解决方案很简单,过程很艰辛。 先介绍一下场景:公司某网站产品的一个页面加载速度非常慢,完全加载完 ...

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

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

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

线上环境:get='_blank'>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.

五、自己写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

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

     网站优化实战

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

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


原标题:网站优化实战

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录