经过了半年紧张而蛋疼的开发历程，项目终于走上正轨；测试组也招了，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前端解决方案来做脚本和样式表的合并、压缩，雪碧图的合并，静态文件名的变更等等操作。
⑥反向代理
通过使用反向代理缓冲服务器减轻资源服务器的压力。
至此系统优化就暂告一段落了。