case-记一次业务高峰期接口超时问题

最新推荐文章于 2022-08-22 09:47:42 发布
最新推荐文章于 2022-08-22 09:47:42 发布
阅读量484 收藏
点赞数
分类专栏： 新的开始 JVM
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/han_dada/article/details/103082674
版权
本文记录了一次业务高峰期接口出现超时问题的处理过程。服务器CPU打满，TP99飙升，经过查看服务器指标、紧急扩容及问题分析，发现CPU打满的罪魁祸首在于String的replaceAll方法使用不当。优化后，性能显著提升，QPS达到预期，GC情况改善，提示开发者在编写代码时需考虑高并发场景下的性能问题。

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

一、背景

服务器出现CPU打满报警，并且服务TP99飙升至1.3s+，依赖方反馈大量超时。

二、处理过程

1.查看服务器指标

首先查服务器的各种指标，根据指标值和趋势大概确认问题。可以看到CPU已经很耗尽了，load彪高比较严重
在这里插入图片描述
在这里插入图片描述
而且此时ygc的次数和耗时都有明显增加，这些指标都会严重影响TP99.
在这里插入图片描述
在这里插入图片描述
上边这些趋势图和业务QPS趋势吻合，初步推断是由于超过单机处理QPS阈值。

2.紧急处理

  1. 根据初步推断采集CPU数据保留现场
  2. 根据初步推断结果采用扩容方案进行止损。果然扩容后服务趋于稳定。

三、问题分析

1.TP99为什么升高？

因为CPU打满，

最低0.47元/天 解锁文章
如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，如何解决？
悟已往之不谏，知来者之可追
04-19 858
问题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 分析 你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于
Flink大数据量调优思路总结（一）
数据与算法架构提升之路专栏
09-15 638
flink 性能优化，大家可以先实践后,发现瓶颈后再来阅读此文。根据实际情况调优，没有万能的法则
压测遇到连接池请求等待超时报错分析与解决
qq_19903753的博客
01-16 1万+
压测遇到连接池请求等待超时报错分析与解决 1. 概述 在对项目进行压测时，我们发现在压测进行一段时间后，会出现连接池等待超时的错误，为了使系统在高并发、请求量激增的时候也能保持稳定，我们必须对这个错误进行分析并解决。最后的解决办法是将springboot的配置文件中添加一条配置：spring.jpa.open-in-view = false。我想从头开始，对出现的问题进行分析，再一步步缩小解决办法...
关于 Redis 性能细节
xingduan5153的博客
09-27 118
聊聊内存存储，redis作为分布式内存缓存，性能极高，但是在高并发读、高并发、大存储量写的场景下很多东西要注意，不然可能达不到预想性能效果。不能用透明方式去使用，而应该多去了解架构以及具体实现。不去了解细节，在高压力应用下，可能会对线上服务造成很大影响，达不到高可用。 关于数据结构，数据结构redis支持很多种，现在要探讨一件事不是这么多种数据结...
TP99 TP999
Mar.三月
03-11 6977
带你理解下啥是tp99 我们现在已有认知：一次请求从前端到后端的请求时间，这个接口的总时间=在网络耗时+服务端处理的耗时。这个通常是一个普通人可以关注到的点，也是最外漏的点。 但是刨去网络耗时外部原因，有没有对服务端处理真正的耗时进行过研究。 服务端耗时=请求到达服务端，服务端开始处理，到最后响应的时间。 接口tp99耗时：就是衡量接口性能的指标，tp99越低，接口性能越好。根据对一个 接口反复测试耗时时间，接口的平均耗时其实就约等于tp99耗时，拿着个值就可以去监控上配置，当接口的tp99耗时超过
【实战】聊聊幂等设计
superjava_的博客
01-04 1656
前言 大家好，今天我们一起来聊聊幂等设计。 什么是幂等 为什么需要幂等 接口超时，如何处理呢？ 如何设计幂等？ 实现幂等的8种方案 HTTP的幂等 1. 什么是幂等? 幂等是一个数学与计算机科学概念。 在数学中，幂等用函数表达式就是：f(x) = f(f(x))。比如求绝对值的函数，就是幂等的，abs(x) = abs(abs(x))。 计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。 2. 为什么需要幂等
使用Jmeter遇到随机取值的需求怎么办？
软件测试技术交流分享
08-19 1369
虽然Jmeter能用来做参数化的组建有几个，但是貌似都没有随机取值的功能，所以我们可以用函数__CSVRead()来实现：
Mongodb特定场景性能数十倍提升优化实践(记一次mongodb核心集群雪崩故障)
github_39037504的博客
10-04 523
问题背景 某核心JAVA长连接服务使用mongodb作为主要存储，客户端数百台机器连接同一mongodb集群，短期内出现多次性能抖动问题，此外，还出现一次“雪崩”故障，同时流量瞬间跌零，无法自动恢复。本文分析这两次故障的根本原因，包括客户端配置使用不合理、mongodb内核链接认证不合理、代理配置不全等一系列问题，最终经过多方努力确定问题根源。 该集群有十来个业务接口访问，每个接口部署在数十台业务服务器上面，访问该mongodb机器的客户端总数超过数百台，部分请求一次拉取数十行甚至百余行数据。 该集群为2.
数据库---MySQL读写分离的方案以及坑
小诚信驿站
04-12 372
强制走主库方案； sleep 方案； 判断主备无延迟方案； 配合 semi-sync 方案； 等主库位点方案； 等 GTID 方案。 一、强制走主库方案 强制走主库方案其实就是，将查询请求做分类。通常情况下，我们可以将查询请求分为这么 两类： 对于必须要拿到最新结果的请求，强制将其发到主库上。比如，在一个交易平台上，卖 家发布商品以后，马上要返回主页面，看商品是否发布成功。那么，这个请求需要拿到 最新的结果，就必须走主库。 对于可以读到旧数据的请求，才将其发到从库上。在这个交易平台上，买家来逛商铺页.
技术分享 | 接口测试中，请求超时该怎么办？
软件测试小迷糊
08-22 752
A 发送请求，然后等待 B 的响应，同时开始超时计时，如果在超时时间内成功接收到响应，则结束等待和计时。如果到了超时时间还没有接收到响应，则结束等待同时此次通讯失败，这个过程叫做请求超时。在接口自动化测试过程中，也常常会碰到请求超时的场景。通过 setParam() 设置超时时间，第一个参数为连接的类型，第二个参数为超时的最大时长，单位是 3000 毫秒。编写三条测试用例，在 test_two 测试用例中设置超时时间为 3 秒，超过 3s 还没有得到响应的话则抛出异常，然后正常执行后面的测试用例。
调用接口超时处理方案
windy博客
01-16 4万+
调用接口超时 处理方案大型项目存在多个子系统。如库存，订单系统。1.增加超时时间假设A系统有个方法methodA，会调用B系统的methodB这个http接口，如果mehodA不追求超快的响应速度，那么你在调用methodB这个http接口时，可以增长超时时间，例如10秒超时。因为经常在某些时刻，由于网络原因或者系统原因，调用method会超时的。2.尝试多调用一次如果第一次调用methodB超时了
接口超时问题
zhoudirui的博客
07-23 3995
在做项目中会遇到一种情况，公司内部或者外部对接的API接口会有超时的情况。 这边列举几个场景下的处理方式： 1.偶尔超时，同步调用接口：a.超时时间适当加长 b.增加重试机制（例如: 接口请求失败，那么线程睡眠1分钟后重试） 2.经常超时：用中间件 如MQ ，将消息处理解耦，异步处理。 ...
性能测试监控TP50、TP99、TP999含义
泡飞的博客
04-12 2万+
性能测试监控TP50、TP99、TP999含义 首先放一段google到的一段解释： The tp90 is a minimum time under which 90% of requests have been served. tp90 = top percentile 90 Imagine you have response times: 10s 1000s 100s 2s Calcu...
数据库慢查询导致接口大面积性能下降
qq_36180997的博客
04-07 2281
背景 从监控pinpoint中看到业务高峰期，接口响应时间呈现一柱擎天的姿势。 分析 数据库监控 cpu打满、内存使用了80%，数据库连接使用了80左右，配置了800，存在大量空闲。 查看慢sql日志，发现慢sql数量飙升。 接口监控 大量接口在getConnection()时消耗了大部分时间。 查看数据库连接配置 发现数据库配置了最大20的连接数。超时时间20s。 原因 慢sql导致大量请求阻塞在获取druid连接资源上。 解决方案 增加数据库配置，调整成8c16g。因为调整了最大连接数，数据库压力可
Jmeter接口测试+压力测试
热门推荐
github_27109687的专栏
05-14 29万+
jmeter是apache公司基于java开发的一款开源压力测试工具，体积小，功能全，使用方便，是一个比较轻量级的测试工具，使用起来非常简单。因为jmeter是java开发的，所以运行的时候必须先要安装jdk才可以。jmeter是免安装的，拿到安装包之后直接解压就可以使用，同时它在linux/windows/macos上都可以使用。   jmeter可以做接口测试和压力测试。其中接口测试的简单操作
​Top99 超时排查思路
dam454450872的博客
12-07 2017
这篇文章想分享 Top99 超时排查的思路和在工作中主动向身边的同事学习的一种意识 背景介绍 我们的系统 Top90 稳定在 19ms 左右，Top99 稳定在 46 ms 左右，Top...
接口性能测试报告样本-含分析内容2
banlunpiao0704的博客
02-14 466
新的测试报告，做性能前，最需要确认好测试环境，有的时候客户经理不太明白，性能测试是怎么回事，问测试要公网的测试报告，尤其是后台的性能测试，我们只能保证其内容效率，公网测试性能相当不严谨，难道移动联通哪天断网了也是我们得事情喽？，所以我认为所有的性能均应该在内网环境下进行，性能而是一个是验证其服务器峰值，一个是验证其服务器最优值的稳定情况。 报告如下： 此次测试的为坐标偏转接口，验证...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值