系统优化之旅

通过了半年紧张而蛋疼的开发历程，项目终于走上正轨；测试组也招了，UI也招了，而项目需求也暂时没有大的改动了。

在此风平浪静的阶段，项目也启动了压力测试。作了几年的.Net开发，倒还真没有应对太高并发的场景，现在这也算是机会与挑战同时到来吧。

 

---

 

①测试第一回合

　　简直是让我无地自容的结果：200个并发登陆操做，成功率不足50%！真是日了狗。

程序的优化我是作了的，自认为这一块已经没有效率低下的代码了，但是这。。

　　解决：首先想的是IIS中的最大并发链接数，看了一下，默认的数值就已经至关的大了。（固然 IIS的最大并发链接数是能够经过配置来实现更大的并发链接数的）

既然不是IIS的链接数限制，那数据库的又如何呢？

查看了一下数据库链接字符串，没有发现关于最大链接池数的设定，默认是100，那这就确定是问题之一了！

②测试第二回合

添加了Max Pool Size后，又进行了一遍并发测试，结果当然是比第一次有提高，但仅是将将达到50%成功率而已。

既然不是受到并发数量的限制，那应该就是效率的问题了。一瞬间突然想到前期光顾着开发，根本没有想过优化，也没有想太高并发的状况，数据库里索引之类的都没有加。

找到登陆用到的几个表，根据查询条件添加了非汇集索引。再次开启测试

查阅的关于索引的文章  

③测试第三回合

此次用了5000的并发（单纯的执行登陆相关方法）成功率100%！

终于松了一口气。无心中看到了记录日志的方法（登陆之类的行为，以及错误都会有日志保存到数据库），想到这个地方也许也能够优化吧，毕竟日志用到的地方仍是蛮多的

记录日志内执行的内容却是不多，只有一个入库操做，可是由于记录日志跟业务代码的执行无关，因此若是异步执行的话，应该也能提升很多效率。

稍做了下修改，再用VS的【性能和诊断】试了1000的并发。跟预想的同样

后台的优化自此就告一段落

④测试第四回合

这回让测试组再用500并发测一下整个操做

每五秒3个并发，就这频率，失败率仍是居高不下，差很少30%，进行到一半后，CPU占用率急剧增加，很快达到100%，而后就是服务器崩掉。

查看了一下线程的CPU占用状况，看到是网站应用的CPU使用率达到了99%。

初步判断的是并发访问页面致使大量的静态文件加载从而形成这个问题。好，那就作静态资源服务器。

把系统使用的静态资源放到一个新站点下，把登录页和首页用到的js、css、img的URL都手动改为绝对路径（即静态资源服务器中对应的URL）。修改路径这个操做是能够简化的，接下来的一段时间我使用FIS3来完成这些事情。

注意：

把文件放到单独的静态资源服务器上也产生了点小问题，经过控制台发现 有些文件没有获取到，如.woff的字体文件。这须要在IIS中添加对应的MIME类型，同时还要针对跨域添加HTTP响应标头 

Access-Control-Allow-Origin：*

 一切就绪，从新发布。

 

⑤测试第五回合

这回并发成功率的提高并无太大，不过CPU使用率恢复了正常，彻底没有因并发而产生太大的起伏。

----------------------------------------------------------------------------------------------------------

事情到此就暂告一段落了。接下来的时间就是优化前端了

由于我发现就算是使用了静态文件服务器，有些事情完成的还不是很理想，

一是文件的本地缓存作的很差，致使刷新页面的话，仍然要从服务器下载或者发请求

二是加载文件的整个过程耗时过长（相对）

 

接下来的时间就一直追踪这两个问题点处理方式。

开始的时候发如今全部的请求中 Response Header里的Cache-Control都是no-cache。

这致使任什么时候候都要去服务器去资源。试了各类方法各类百度也没找到。最后发现dudu的一篇文章解决了这个问题

http://www.cnblogs.com/dudu/p/iis_user-mode_caching_cache-control_public.html。

此外 仍是用了大百度的FIS3前端解决方案来作脚本和样式表的合并、压缩，雪碧图的合并，静态文件名的变动等等操做。

 

⑥反向代理

经过使用反向代理缓冲服务器减轻资源服务器的压力。 

 

至此系统优化就暂告一段落了。