压测实例一

业务背景

考生登录系统后，进入到考生课程页面，访问人数达到一定量之后，系统响应缓慢，无法查看课程，亦无法考试。经测试系统在处理考生查看课程页面的接口的服务器的吞吐量仅为100tps，所以当大量学生进入系统时造成了服务器处理缓慢，无法处理过多的请求。
修改后的服务器项目架构图，增加了缓存

修改的内容

客户端在请求学生课程详情时分成了两个部分，先去server端将HTML和静态文件请求回来，在将学生的数据拿回来，由浏览器本身计算后显示到页面上，将常用的js文件和图片放在nginx上，减少用户在刷新页面时一直往server端发送请求，减少流量和减轻服务器的压力，将所有的图片、js等文件进行再压缩减少访问的流量。
代码部分，在数据库中增加了一个中间表，学生每次更新课件、考试、答疑等的成绩后数据也同步写入中间表，下次学生在刷新成绩时就不需要进行多表查询后计算成绩在返回前端，现在只需要查中间表完成计算即可。MemoCache中的数据也是取自这个中间表。

压测工具

简单接口使用 ab (最多 100 个并发)
复杂测试使用 JMeter

压测方案

使用 Gui 模式编写 JMeter 脚本，测试通过后在Linux服务器内网首先进行压测使用，推荐每台机器300 个并发，压测完成后查看测试报告。
获取同样的数据提供 2 个接口:
直接访问数据库数据
从缓存获取数据
查看压测报表时能够比较 2 种接口的压测数据
提供接口只返回计算 1+1=2 的结果，不访问数据库也不访问缓存，压测这个接口纯粹是为了测试 Web Server 的处理能力有没有问题，此时与数据库缓存等第三方服务无关也不使用目前的软件框架

压测结果

单台服务器测试结果如下：

单台服务器的数据，300个线程1秒的并发，循环1000次，整体数据走缓存的响应时间和吞吐量都略好于直接访问数据库无缓存的。

两台服务器做了一个小集群之后测试结果如下：



两台做了集群之后发现，同样的脚本系统吞吐量上去了，但是线程直接访问数据库的响应时间却增加了不少，走缓存的没有明显变化，还是很快的，最后发现是数据库设置了单点连接，允许的连接数较少，所以导致响应的速度变慢了。

总结

服务器使用负载均衡:
对每台服务器单独压测，调至单台最佳的状态。
对集群进行压测
根据压测的情况，调整服务器端 Linux 的参数 (Nginx, Web Server, MySQL 等所有 Linux 的机器都要设置):
最大打开文件数
连接自动释放时间
数据库、Redis、MemCached 的最大连接数
从 Web Server 独立压测 MySQL、MemCached、Redis 的处理能力
服务器内网压测、外网压测
压测的时候也使用浏览器打开对应的页面，可视化的查看是否有响应
及时调整脚本，最好可以多台测试机采用分布式测试，增加并发数量来模拟用户的请求情况，可以先只在内网测试，内网测试完成后系统稳定运行了在去外网进行分布式压测。