51_JMeter高并发压测后卡顿

好，同学们，咱们继续那上述测试都通过了我们平台。搭建好了，我们将以下面的为根基来给大家演示熔断和降级，那再复习一次小小的业务啊，这个是故意要耗费三秒钟，大家看。没问题吧，但是没有报错，正常出来这个请大家看是不是秒回，现在的问题是它们两个CT抽了，OK。这两个方法是不是都在我们的这个payment这个里面，都是payment能够对外提供的服务，暴露的服务接口O了吧，好的，那么接下来同学们。来吧。上述在高并发的情况下呢，还没测过，都是在非高并发的情况下。还能够满足听懂，但是假如说现在杨哥干坏事，你现在是一个来反问这个，一个来反问这个，各取所需，这个是不是很快就回来了，这个转了三秒钟的圈圈也很快回来了，你就当现在只有两个线程来访问，但是大家都明白，我们做分布式微服架构都有一句话，是不是叫量变引起质变啊，现在。

不好意思啊。干嘛呢？吉米塔干他2万个并发，活活的压死80012万个请求，我们都去访问我们的timeout，这一波能跟上，那么什么意思呢？来，同学们，咱们先干活，再说理论。打开我们的吉米塔啊，高并发的压力测试啊，那么杨哥呢，给大家讲解过这个呢，就不再啰嗦了，直接拿过来用了啊，前面你们都跟着我学了这么长时间，那么首先测试计划添加干嘛？我们这是干它一个线程组啊，比方说线程组现在这个是2020。

02OK，那么线程数两百一秒钟一个，现在干它100个循环次数，那么100乘以200，那么兄弟们。多少啊，是不是就是我们这儿的2万个并发直接要干到这个打到这个上面啊，那么所以说请同学们按照我这个配置啊。做起来，然后。我们呢，直接呢，来试试，在这块完了以后，我们这个线程组，我们直接先给它保存，保存完了以后，那么同学们，我们在这儿找到我们的。逻辑控制单元，我们的原件、配件，我们要发的是一些什么？真真真真的HTTP的请求，那么在这一块的以后同学们，我们的这个路径外部服务器的IP，那么是不是我们的local host端口号是不是我们的8001啊，那么接下来这个HD品求，我也是叫202002，这这么说能跟上，那么我们的这个路径，那么弟兄们。

干什么呢啊？我们用这个啊，那么现在相当于说有2万个线程要去访问这个链接地址，同学们这一波能不能理解。能跟上，那么就是我还没讲，你也应该有种感觉，那这块是会被耗死啊，这么说能跟上好最后再看一次啊，现在我还没有高频发压测呢，在我们这个time out这。来三秒钟过了，但是这个OK，这个啊，请看是不是马上就秒回了，无所谓，现在是线程量小，那么下面同学们这个时候弟兄们202002这个干起来。OPPO host8002，我们找我们自己的这个payment，带着这个超时的，那么这个时候已保存好了，那么线程组下面又发这么一个2万个请求，我们一起动，兄弟们，啪啦啪啦啪啦这块是不是干过去了，这个时候请看我们再来一次啊。

这个时候注意有没有发现我们的三幺它现在也要开始转圈圈了，以前是根本不会转圈圈的，这么说听不听得懂，三幺看是不是开始转了，那么这块我们也给它转，这块也给它，那么好，大家看三幺是不是被拖慢了，这么说听懂了吗？那么我这个是2万个线程，听懂了吧？那么注意一部分，有些同学别打那个聊天窗口。差不多了2万个线程，你自己的机器，你干它一个亿一个亿个线程，去反问你本子是不是压坏了，OK，我们这主要是看这个演示结果，就是大家请看，我们现在啊，噼里啪啦，噼里啪啦是不是还在往后面发着呢，这么说能跟上，你看我这虽然说打出去了，这块发出去了，但是我到这边都还没有处理完呢，每次啊都要等三秒钟，那么大家请看。

怎么样？三幺是不是开始会转圈圈，以前我是根本不慢的，但是压力一大，线程一多，我被你拖累的变慢了，所以说呢，我们得到的演示结果就是两个都在自己转圈圈，那么兄弟们为什么会被卡死啊，当然啊，我这先把这个停掉。那么。OK，停完了以后，那么这块后台清空，清空完了以后，那么现在啊，大家请看没有人再给我发这些。压力测试了，那么这个时候请看我们回复到正常哈，假设处理完了一个线程缓慢三秒钟，大家请看这块三加二，只要是OK的，这个是不是不应该转圈圈，它可以马上就秒回，所以说呢，我们得到如果刚才。高并发去砸一个rise接口微服，那么这个时候不好意思啊，产生了连坐效应，我2万个找的是它，一堆人打这个，而只有一个线程去找他，我这个是OK，最简单的，我们都明白平时是不是马上就秒回。但抱歉，由于。

你跟我是在一块儿的，在一个微服里面大规模的资源。打到这儿，那么现在微服务就不得不集中资源去处理这些高并发的请求，好比现在武汉疫情，全国的医护人员是不是都在支撑武汉一波一波的送进去，去共同面对新冠肺炎，那么平时这个好端端的，由于现在你这个重压之下把资源都抽空，抽空了，那么就会导致我这个是不是也会出现等待卡顿，延时的现象，转圈圈听懂，那么理由就是一个。因为Tom k的默认工作线程数，因为spring它默认集成的Tom k，哈，它里面呢，有一个Tom KT的容器的线程池，默认是十个工作人员，你现在干他2万个，所有的资源都被抽掉去处理那个了，那么没有多余的线程来分解压力和处理，就导致我们即便是我们的。

刚才没有转圈圈的这个欧K也变慢了，被拖累了。清楚啊，所以说我们的JA me的压测结论就是上面还只是服务的提供者，8001干什么啊，自测什么意思啊，兄弟们都明白，我这还没有添什么consume呢，我们自己先把自己收拾干净，打扫好屋子才好请吃饭，对吧？那么现在我们自己如果是干他2万个病发的话。就会转圈圈卡顿变慢，那么假设此时外部的消费者巴林也来访问的话，那么我们这个八零消费者是不是只能肝胆甚至被拖死，最终导致消费者八零端不满意，服务端8001被拖死？打满CPU和线程，所以说这种情况下非常的危险，我们必须要有S这样的容错限流框架来对我们系统进行保护，OK，好，那么同学们这个压测的问题我们就给大家说到这儿。