项目性能测试问题记录（更新至2018-7-25）

最新推荐文章于 2024-07-18 13:54:30 发布

ltswind

最新推荐文章于 2024-07-18 13:54:30 发布

阅读量660

点赞数

分类专栏：性能实战

本文链接：https://blog.csdn.net/ltswind/article/details/81140169

版权

本文记录了一次针对基于Spring Boot二次开发的Ark架构项目的性能测试过程。在测试中发现了日志文件占满磁盘、接口响应时间与并发关系、第三方接口调用延迟以及MongoDB性能瓶颈等问题。解决方案包括调整日志级别、优化并发策略、异步批量写日志以及关注连接池和CPU使用情况。

摘要由CSDN通过智能技术生成

新项目上线。在开始试点推广使用之后，对项目进行性能测试，以便于后续项目全面推广的准备。

项目使用的是公司内部对Spring Boot进行二次开发的内部Ark架构。只负责公共服务端的测试，所以流程为：负载机——网关（分发）——应用APP（调用内部其他系统、DB等）。

压测中实际发现的问题。

1、在前期对应用主机进行负载测试的时候，单主机的测试的TPS结果较为良好。但是后续随着测试的继续，同一个接口，同并发下的TPS逐步变差。由于环境没有变化，推测为负载测试中持续产生数据的问题，检查mongo使用情况，发现mongo响应正常。后发现应用磁盘中，日志的空间几乎占满。删除日志文件，并将系统日志级别从info改为error，后恢复正常。

——性能测试，前期工作需要确认系统日志级别。

2、测试中，通过对接口的大并发压测，测试系统单主机的极限的时候。最初的150并发，TPS响应为231；将并发增到为160,180，TPS响应均为229。TPS无明显变化。网关、Tomcat、数据库资源均有冗余，主机CPU使用率三个场景均为100%，内存使用率40%以下。实际分析情况为主机CPU已到上限，不断递增的并发，只是不断地进入系统处理的排列。所以并发增加。但是TPS没有变化。持续降低并发。最终发现30并发的时候TPS已经达到230了。

——性能测试，进行测试时，先不用具体的并发数进行测试，而是先简单调用，看接口的相应时间，然后进行一个大并发的测试，将并发的递增时间延长，例如300并发，递增时间为600秒。然后看TPS的递增的拐点，以初步核实实际最高并发和峰值