- 博客(92)
- 收藏
- 关注
RSS订阅原创 异常场景性能测试
我们对异常场景最基础的预期就是，在异常出现的时候，系统能快速恢复，这也是我们做异常场景的价值。如果不能快速恢复，业务也就随着异常掉下去了，这时候我们就要提 Bug、提风险。在这篇文章中，我们模拟了应用级异常、操作系统内部异常、容器级异常和整个操作系统级异常，在当前的微服务架构中，这些都是经常出现的异常场景。当然，它们并不能覆盖微服务架构中的全部异常场景。你可以根据上节课讲的异常范围图，把缺少的异常场景设计出来，以覆盖全面。
2023-05-29 17:02:46
567
原创 性能分析思路
首先，要准确的判断瓶颈点。通过什么来判断呢？TPS曲线。TPS曲线能够告诉我们系统是否有瓶颈，以及瓶颈是否与压力有关。为什么不需要响应时间曲线来判断呢？因为响应时间主要是用来判断业务快慢的。我们要确定我们设置的性能场景是正确的，线程是逐渐递增的，而不应该一上来就上几百个线程。原因：1、直接上几百个线程不符合一般情况下的真实场景。
2023-05-29 16:56:37
178
原创 容量规划思路
当压测单机部署的系统时，我们会采用人工的方式不断增加测试负载直到单机系统的吞吐量指标到达临界值，由此就可以知道单台机器的处理能力。理论上整个集群的处理能力将等于单台机器的处理能力乘以集群的机器数，但是实际的集群整体处理能力一定小于这个值，但具体小多少就是要靠实际的测试验证了。比如，企业级软件产品的目标用户规模通常是可以预估的，那么我们就可以通过这些预估的系统负载计算出软件部署的集群规模。容量场景中用到所有的接口，这些接口是有上下的业务逻辑关系的，所以要根据业务逻辑做参数传递，而不是通过造数据来做参数化。
2023-05-29 16:49:25
344
原创 基准测试思路
即在基准场景中，我们要把 CPU、内存、网络、IO 等资源中的任一个耗尽，因为在这种情况下，我们很容易从全局监控的性能计数器中看到现象，可以接着去跟踪分析。如果不会预估容量，可以直接多加一些线程，然后在递增的过程中查看曲线的变化；强调一下，如果你不会预估容量，可以直接多加一些线程，然后在递增的过程中查看曲线的变化；即在基准场景中，我们要把单接口的 TPS 调到最高，以免成为容量场景中的瓶颈点。解决单接口基准场景中遇到的性能问题：也就是说，当我们在做单接口测试时，碰到了性能瓶颈一定要分析解决。
2023-05-29 16:41:59
75
原创 稳定性测试思路
稳定性测试主要是为了发现系统在资源的创建和销毁、内存分配和释放、线程的创建和销毁、网络链接创建和断开上面的问题。稳定性场景是为了找出业务积累的过程中出现的问题。所以，如果业务积累量不能达到线上的要求，就不能说明稳定性场景做得有意义。
2023-05-29 16:41:35
648
原创 JMeter+InfluxDB+Grafana进行jmeter性能结果展示
Jmeter是一个开源的分布式压测工具，在GUI模式下，可以采用聚合报告或者HTML文件来查看压测结果，但是在高并发压测场景下，我们一般采用命令行方式来执行Jmeter脚本，但是命令行这种方式压测结果不够直观，在反馈上级领导时，也不美观。因此可以把JMeter的压测结果写入InfluxDB，然后通过Grafana把InfluxDB中的压测结果展示出来。一、安装InfluxDB数据库二、安装Grafana1）更新brewbrew updatebrew ins...
2023-02-22 10:57:03
328
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人