大家好，我是IT修真院北京分院第30期学员，一枚正直善良的java程序员，今天给大家分享一下，修真院java任务中的一个知识点：Redis性能分析报告

（1）首先是系统可以在500ms返回时的tps：

   经过很多次变更调试，最终确定全部请求时键500ms以内的线程数最大是22，最大循环次数1：

也尝试了微调，比如23线程：

也就不满足条件了，也尝试稍微加上一次循环，也就是22线程2次循环：

也已经不符合条件。

那么符合条件的就是22线程1s启动循环1次，它的tps视图：

因为线程数和循环数都很小，总请求就很少，所以它是一条直线。那就得出结论了，系统可以再500ms内返回时的tps是18.3。

 （2）系统宕机时候的负载：

 首先我得定义宕机，我认为测试被迫停止或者就是宕机，没有按照设置跑完就宕机了。

100线程1s启动的情况：

虽然没有宕机，但是响应时间已经非常的长了，但是这还没宕机，调到200线程：

虽然各个参数都挺惨，但是仍然没有宕机，接下来调到300线程：

嗯。。还没有，直接加到500线程：

已经卡住了，并且出现了错误，在观察过程中错误率一直在波动，是因为错误在不断的出现，可以认为此时已经宕机了。

 于是结论是：500线程1s启动的时候宕机了。

  （3）TPS稳定时的响应时长：

  那么调整线程数，达到让tps稳定：

可以看到除了画圈的部分，整体比较稳定，分别对应的是0-20s和49-59s以及1.19-1.39s，那么查看这几个区间的响应时间：

那么可以看到这写区间的响应时间，但是这个图并不是很好，因为刻度太大了，我们只能估摸着来，稳定的时候大概在1.5s左右，不过很多值是小于这个数的

 2.那么接下来就是模拟缓存穿透的情况：想想一想要怎么模拟，而且缓存穿透是什么？

  这样说吧，本来存在缓存的时候，请求会从环中取出数据，而有的时候突然跑到了数据库中去拿数据，就是缓存穿透了，缓存没能拦住这个请求。也就是说要创走啊这样一个情况：让请求又从缓存拿的，有从数据库拿的，然后对比一下情况。看看缓存穿透的时候会发生些什么。

  那么需要在代码里面更改一些，加上一个判断，来查看一波

public static int i =0;//定义全局静态变量，来保存数据

public ListgetAllPros(){

i++;

   System.out.println(i);

   List pross;

   if (redisUtil.get("pross") !=null&&i%9!=0){

pross = (List)redisUtil.get("pross");

       System.out.println("从缓存中取到的哦");

    //   return pross;

   }else{

pross =pageDao.getAllPros();

       redisUtil.set("pross",pross);

       System.out.println("从数据库取到的哦");

     //  return pross;

   }

return pross;

}

  这样的话，只有9的倍数次访问的时候才会模拟击穿缓存。

很清晰。

然后在使用jmeter测试的时候效果并不直观，数据太过笼统，于是选择了postman来测试：

这是一次缓存穿透的响应时间。然后下面是直接使用缓存的：

然后赶上下一次的穿透：

还是比较直观的，大概20%的提升吧，而且我觉得在多线程访问的时候肯定效果更好。