使用JMeter对Company应用进行压力测试

最新推荐文章于 2024-08-22 01:20:20 发布

转载最新推荐文章于 2024-08-22 01:20:20 发布 · 85 阅读

CC 4.0 BY-SA版权

通过Kubernetes集群使用JMeter对基于微服务的应用进行性能测试。针对登录认证造成的时延及多个接口的压力测试，发现经理服务为性能瓶颈。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

　　压力测试是评估网络应用性能的一种有效手段。如今越来越多的应用被拆分为多个微服务且每个微服务的性能不一，有的微服务是计算密集型，有的是IO密集型。

　　因此，压力测试在基于微服务架构的应用中扮演着越来越重要的角色。本文将在Kubernetes集群中使用JMeter 3.2对Company应用进行性能评估。

　　在上文《微服务化后的按需精细化资源控制》中已了解到Manager服务的资源需求最大，本次使用JMeter对Company进行精细的性能测试。

制定JMeter测试方案

　　制定的测试方案为：

1. 由于登录认证会造成较大时延，故在压力测试主体运行前完成用户认证事宜；
2. 对Company应用多个接口持续并发访问，QueryWorker、QueryBeekeeperDrone、QueryBeeKeeperQueen分别对Company中的服务发起请求压力。

　　测试方案文件笔者已托管在github上，可直接获取：

　　在JMeter界面导入测试方案，导入后，可在JMeter界面看到具体测试方案，如下图：

启动测试

启动Company应用
修改hosts.csv文件，使其匹配正在运行的Company应用中manager的服务地址。其中，默认的hosts.csv文件内容为：
127.0.0.1,8083
运行测试，启动200个并发线程发起请求压力，并设置测试时长为600秒：

测试结果

　　在不同并发度下的测试结果如下图所示：

　　可以看出：

　　为了找出性能卡在了15并发度时的原因，我们回看了Heapster上的监控数据。如下图所示。显然，经理服务是当前系统的瓶颈所在。它在吞吐量为1000 req/s时达到了最大的CPU负载。相对而言，其它服务对资源的需求的增长速度要慢得多。

　　由于经理服务的日志是直接输出到stdout上的，且JMeter的测试端以单机模式运行时可能并不能同时模拟出足够的并发量。依此对在同一并发度（200）下不同log的设置（log4j1 stdout，log4j2 stdout，log4j2 异步，无日志输出）进行测试。运行结果如下所示：

　　从上图可以看出：

JMeter单机测试和分布式测试的性能都非常接近，说明单机模式的JMeter测试暂时足以模拟出足够的并发数来处理当前的测试场景。
日志的输出对系统的性能造成了较大的影响。可以看到，异步输出日志的方式能比同步输出的方式提升接近100%的性能。因此，在生产环境下使用完全同步输出日志的方式可能并不会有较理想的性能。
log4j2的性能相对于log4j1而言有较大的提升，同时从下图也可看出，log4j2的内存使用量也比log4j1有所减少。因此，建议使用性能更佳的log4j2替换掉陈旧的log4j1。

　　从上图可以看出，尽管异步日志的方式能极大地提高系统的吞吐量，但它同时也占用了较多的内存。

　　由于Company应用只是一个简单的用例，在测试过程中各个服务的内存使用率都相对稳定。然而，相对告示栏服务（使用go语言编写）的内存使用量而言，其它以Java来编写的服务则占用了较多的内存。

总结

　　对应用进行压力测试往往能在应用投入生产环境前帮助我们找出服务中潜在的问题。压力测试也能模拟生产环境，从而来验证服务是否已达到规定的性能指标。而根据压力测试的结果，我们可以权衡Pod部署时的设置来保证SLA的同时获得最大的系统吞吐能力。

　　基于微服务架构的应用不仅在设计、编码及测试方面变得更加灵活，同时也使得部署更加方便。基于微服务架构能够保证资源的弹性伸缩极其迅捷，我们可以根据服务的真实可承受压力设置不同的副本数和资源配置来节约资源。此外，在云上也能借助其弹性伸缩能力使得服务能够应对访问风暴。

　　请点击左下角“阅读原文”查看更详细的测试过程。