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

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

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

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

    项目使用的是公司内部对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的递增的拐点,以初步核实实际最高并发和峰值TPS(如到60秒的时候产生拐点,则为30并发达到系统TPS峰值)

    3、压测中,通过Pinpoint监控各个线程执行情况,其中部分高耗时接口,检查时,发现耗时主要在于调用第三方接口。针对于此,如果第三方系统有性能环境,则应该使用性能环境支持。如果没有性能环境,而本身作为瓶颈,则可以考虑修改本系统代码,暂时屏蔽调用返回。或者让第三方系统提供他们的接口性能情况,以此增加延时作为模拟。(以上处理,在最终的测试结果报告中,均要进行实际说明。如果第三方无法提供支持,也要通知根据自己系统的压测结果和生产预估调用,通知第三方)

——测试准备中,对于要测试的功能,是否调用第三方,要提前了解,并做好准备。

——2018-7-23

   4、压测中,先对单主机进行压测,最大TPS为235,通过网关对单主机进行压测,最大TPS为231。网关转发影响小于2%。可以接受。对网关转发多主机进行压测,TPS上升。但是压测的TPS曲线波动异常。呈现锯齿状,有很多影响延时严重。减少主机,单台主机并发到TPS峰值,响应正常,曲线正常。增加为两台主机并发到TPS峰值,响应正常,曲线正常。当增加到三台主机的时候,并发到TPS峰值,或者和两台主机同样的并发,响应均出现异常,TPS曲线偶发锯齿。降低并发,使三台主机的TPS和两台主机的TPS峰值一致,TPS曲线正常。通过PinPoint监控看大延时的任务,确认延时高的响应都是到mongodb写日志和查数据的任务,确认是mongo导致的异常。无法支持递增的并发。继续跟进处理。

——2018-7-24

——发现的mongo问题,主要还是在写日志上引发的。同时确认当前系统架构,单应用的连接池只有10个链接,使用完后释放占用链接回链接池。连接池问题,架构组正在处理,下一个版本即可支持。写日志的问题,变更系统写日志的方式,将原本的同事写日志,变更成异步批量写日志。变更后重新进行负载测试,性能瓶颈回归云主机CPU。继续增加云主机测试下一个瓶颈。

——2018-7-25

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值