任 务 六 总 结

今天完成的事情：压测报告的制作，任务七的预热

我任务六的大致流程是：

1.从任务五继承过来的原始项目代码，尝试对主页进行压测。结果：

稳定下来后的TPS：8左右

极限一秒钟的并发：37左右，最后几个线程要好久才能缓过劲来。

因为这里我是拿BADBOY写的脚本，录制了“主页-列表-查询-修改-主页”的一个循环。经过多次测试，发现主要卡顿的地方是在主页，再加上实时性的问题，于是打算后续就对主页进行缓存优化，对比压测结果。

PS:主页的那些优秀学员列表、在读学员总数、优秀学员总数对实时性的要求不高，而学员的增删查改（任务二内容）对实时性的要求很高，所以我任务二的内容没有什么地方可以加缓存的，后面直接对主页进行压测，就不压测其他了东西了（因为其他东西基本上没有什么改动...）。

这里插入一个说明：之前郭伟杰师兄叫我用的是每秒20并发，循环100次的方法测试，但是我这里的任务加了一些新资源（比如js文件,新的css文件和一些字体文件），导致单次请求的流量较大，在实际测试中发生了很多莫名其妙的问题。后面我上了阿里云的监控平台，发现原来是带宽的锅：

1M/s的小水管，峰值居然达到了946kb/s（其实这里的刻度还是大了点，我严重怀疑某个秒时段达到了上限1024m/s）！

所以，在后面的测试中，我只能调低每秒并发数量和循环次数。

本次测试使用的数量：每秒15并发，20循环

2.给首页的动态数据做了缓存，然后压测：

缓存内容：优秀学员列表（随机四个，一小时更新一次缓存）和学员、毕业生的总数

稳定下来后的TPS：10左右

可以发现，数据的波动非常的大，中位数才110ms，平均数居然都1397了！而且300个请求也花了40S才完成，最慢的一个请求居然要30.4S才处理完...估计这玩意真的给用户用的话，要被用户骂死把...所以我决定对任务六做进一步的优化。

3.给nginx添加图片缓存，进行压测。

nginx有关配置：

然后运行后可以在设置的目录下看到：

文件是32位哈希码无后缀名的形式。

接着进行测试，稳定下来的TPS：12左右

可以看出来性能明显好了很多，首先是总时长减少了，最大耗时的请求也减少了一半，但是中位数的大小明显增加了，这说明nginx做缓存消耗的资源还是有一些的，在事务清闲的时候反而体现不了优势，反而会略微地降低性能。不过，当并发达到一定数量后，缓存的优势就体现出来了。

4.因为resin4不支持多实例，之前一直没有做集群。任务六的时候我换用了tomcat，然后做了均衡负载，进行压测：

稳定下来的TPS：12左右，但是曲线明显平稳了许多，少了很多噪点（后面也有一两处断崖，原因我后面分析）。

可以看出来，总时长得到了略微的缩减，效果大约是10%off。但是,可以看出来，中位数的值得到了大大的减小。但是美中不足的是，偶尔会出现卡顿比较久的情况，而且测试了好几次，发现都是在第260左右请求的时候发生。如果抛开这点，只看聚合报告的话，前面的运行速度是比较好的，数字跳的很快的...所以个人推测应该是服务器带宽瓶颈，在260左右的时候达到了1M/S的峰值，就和上面说的一样。但是，阿里云的流量监控是以分钟为单位的，精确不到秒，jmeter的流量也只是一个平均数，所以具体原因也不好确定...

总而言之，负载均衡还是有用的，性能有提升，而且能防止挂一个Tomcat实例就服务瘫痪的情况。

本来想开三个Tomcat实例的，后来发现内存不足，nginx开都开不了，直接提示22类型错误。然后我开了top，发现tomcat和mysql还是挺耗内存的：

其他零零散散加起来都快70%内存了，实在是开不动第三个了....

明天计划的事情：应该开始任务七了
遇到的问题：null
收获：分析了一波数据