Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >记一次服务问题的追踪过程

记一次服务问题的追踪过程

作者头像
用户5521279
发布于 2020-04-15 13:55:16
发布于 2020-04-15 13:55:16
4680
举报
文章被收录于专栏:搜狗测试搜狗测试

背景

最近经常发现一个线上服务的响应时间会变长,分析线上metrics统计,发现偶尔会有一两台机器问题比较严重,经过多番追查,确定了问题,并修复了,在这儿回顾一下这个过程;

服务基本逻辑

客户端不同类别请求,由服务端的不同逻辑处理,每种逻辑处理耗时不同;服务端启动时需加载多组配置数据,供后续不同逻辑使用;

问题表象1

晚高峰时,根据metrics统计,服务整体响应时间变长;但使用测试环境压测未见异常;

  • 分析:可能是新版本客户端的新增请求导致某逻辑处理时间偏长;
  • 方案:抓取大量新版本客户端线上请求对测试环境进行压测;
  • 结果:测试环境问题未复现;

问题表象2

第二天早上,流量低谷时段,又出现服务整体响应时间变长的问题;

  • 分析:将整体统计细化到机器粒度,发现个别机器响应时间变长的现象特别明显,怀疑某些特例逻辑导致服务性能异常;
  • 方案:服务增加debug开关,开启后可抓取特定机器pprof数据生成火焰图;
  • 结果:针对出现问题的机器抓取一分钟火焰图观察(如下)

可见Ahocorasick.Match函数耗时特别长;追查代码后为解决线上风险,暂时屏蔽了用到此函数的新增逻辑;

问题逻辑

用到此函数的新增需求大概如下:服务启动时加载一组词表,当用户请求命中词表中的词时,进行新增逻辑;此处耗时超长的Ahocorasick.Match 函数就是上述需求中对词表进行匹配的函数,查了一下,使用的是第三方的AC自动机库,且这个库在其它功能处也有使用;

问题表象3

测试环境无法复现,线上环境每隔一段时间就会有个别机器出现;

  • 经分析测试环境与线上环境的配置是有差异的:为测试此功能,在测试环境配置中,增加了一些应命中匹配的词表,故在测试环境中按词表中的词条执行测试用例,可以命中新增逻辑;但线上环境配置的词表中并未增加任何词条;如下图:

然后分析函数Ahocorasick.Match逻辑,发现一处bug:当匹配列表没有insert任何词条 且 被匹配内容是ascii码=1的字符时,函数下图处会死循环

之后,构造了相同的条件,在测试环境中复现此问题;由于之前用到这个自动机库函数的其它需求,的匹配列表中均有内容,所以线上一直未发现问题;

问题分析

总结一下由此问题想到的几点测试需要注意的地方:

1、针对第三方库,要持怀疑态度,上线前至少要对主要功能使用到的函数做单元测试

2、理想的认为匹配列表中不insert词条,即可以暂时屏蔽线上的功能;实际上是漏掉了一个影响因素(ac自动机词表为空时,执行match)

3、线上服务要建立应急机制,可能因为某一个影响因素的改变,导致线上稳定运行的服务或函数无法正常运行;

4、github上的开源项目尽可能用star多的

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-04-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 搜狗测试 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
记一次性能测试的经历
工作这么多年,一直专注于自动化和工具研发,对性能方面做的相对少很多。主要还是没有实际的上手机会,没有需求就不能很好的实践,光看几本理论知识的书还是不够的。今天主要就来说说这几次性能测试所经历的“坑”。
上帝De助手
2019/11/10
8090
一个重量级HTTP api的304优化分析与突发失效问题解决
最近查看nginx log排查问题时,意外中发现重量级的主页 list api 304比例已暴跌至不到1%,之前该比例长期维持在30%以上,近期也未改动过相关逻辑,跟进后最终发现是服务端本地cache混用导致的问题。
老K博客
2023/12/18
2150
记一次 Kubernetes 机器内核问题排查
此次排查发生在 2020-11 月份, 一直没时间写博客描述事情经过, 本次正好一起写了吧.
米开朗基杨
2021/04/02
5940
CLS 监控告警:实时保障线上服务高可用性
对于任何一个线上服务来说,可用性都是一个重要的质量指标,用户能否用产品完成任务?效率如何?主观感受怎样?这实际上是从用户角度所看到的产品质量,是产品竞争力的核心,是产品可靠性、维修性和维修保障性的综合反映。
日志服务CLS小助手
2022/07/27
1K0
漫漫优化路,总会错几步!记一次接口优化!
点击上方"IT牧场",选择"设为星标"技术干货每日送达!来源:www.cnblogs.com/cjsblog/p/10573215.html
用户1516716
2019/08/14
4250
漫漫优化路,总会错几步!记一次接口优化!
21个测试高频面试题
项目质量不仅仅是某个人或某个团队来保障的,而是整个团队一起努力的结果,在公司级别需要有一个规范的项目流程
FunTester
2023/08/04
8340
漫漫优化路,总会错几步(记一次接口优化)
本文作者:狂乱的贵公子 原文地址:http://1t.click/kk5 最近做了一个搜索接口的优化,反复压测了四次,终于达到要求了,记录一下,晚上加个鸡腿? 业务逻辑 从OpenSearch中检索
江南一点雨
2019/07/17
3970
漫漫优化路,总会错几步(记一次接口优化)
性能测试学习小结
前段时间小编做了一个压测项目,对压测过程中学到的知识进行了总结,在此和大家分享下:
用户5521279
2019/12/10
6290
全链路压测平台(Quake)在美团中的实践
在美团的价值观中,“以客户为中心”被放在一个非常重要的位置,所以我们对服务出现故障越来越不能容忍。特别是公司业务正处在高速增长的阶段,每一次故障对公司来说都是一笔不小的损失。而整个IT基础设施非常复杂,包括网络、服务器、操作系统以及应用层面都可能出现问题。在这种背景下,我们必须对服务进行一次全方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验。真正通过以下技术手段,来帮助大家吃的更好,生活更好:
美团技术团队
2019/04/04
2.3K0
全链路压测平台(Quake)在美团中的实践
聊聊性能测试中的性能调优的效益
业务稳定性不仅受功能缺陷影响,还受系统性能影响。当系统崩溃时,线上业务也会随之中断。业务不稳定直接带来的是口碑下跌和品牌影响力下降,最终导致营收下降。
漫谈测试
2024/10/23
1630
聊聊性能测试中的性能调优的效益
性能测试实施全过程指南
  通过制定性能测试实施指南,从技术角度对性能测试实施过程中所涉及到的关键技术进行规范,能更好地从技术上来规避系统上线后的风险、评估线上系统的真实能力、根据业务模型摸底线上能力以提前应对。
顾翔
2019/12/23
8320
记一次线上内存泄漏的破案过程
9月的某个上午,业务侧突然反馈线上数据服务响应慢,造成任务积压,正常情况下耗时5ms的服务,单次响应达到了5s量级. 收到反馈后我们马上开始排查服务状况,但发现各项指标很健康,接口平均耗时3ms,p99约为1s,和经验值比无太大差别. 业务侧随后补充反馈是某些请求很慢,感觉是若干pod有问题,当流量打到这几台机器时就会变慢.
用户9580384
2022/10/05
1.1K1
记一次线上内存泄漏的破案过程
稳定性治理二,稳定性分析
支付宝2015年发生了大规模的宕机事件,原因是杭州市萧山区某地光纤被挖断导致,为确保异地容灾、多活,后面专门进行了全链路单元化改造,整个交易链路都进行了单元化改造,并且经常在大促前夕进行单机房演练;
阿甘的码路
2023/08/17
6220
稳定性治理二,稳定性分析
性能测试准备过程总结
性能测试准备过程总结 准备阶段 必要性分析 分析是否有必要进行性能测试; 被测对象分析 确认被测对象,并根据被测对象性质确认测试方案; 测试技术准备 根据被测对象准备测试技术不同协议测试工具、测试重点及方案是有区别的,例如http接口、rpc、websocket、udp测试技术不同,应根据不同的测试对象准备不同的测试方案 目标评估 评估被测服务性能指标预期结果 峰值QPS 已上线的需求可以按目前线上状态评估,这样最准未上线的需求一种方式可以找类似其它功能,没有相似功能的话可以找类似其它产品无法参照的话可按全
用户5521279
2019/10/24
9590
最近做了一个搜索接口的优化,反复压测了四次,终于达到要求了
逻辑看似很简单,当初我也是这样认为的,于是预估5天完成,最后前前后后开发、联调、改bug直到上线差不多花了10天(当然这10天并不是只做这一件事情)。
java进阶架构师
2020/12/17
4180
最近做了一个搜索接口的优化,反复压测了四次,终于达到要求了
带你重走 TiDB TPS 提升 1000 倍的性能优化之旅
今天我们来聊一下数据库的性能优化,第一部分简单介绍一下性能优化的通用的方法,第二部分我们讲一个实际案例。
PingCAP
2021/12/07
1.1K0
最近做了一个搜索接口的优化,反复压测了四次,终于达到要求了
逻辑看似很简单,当初我也是这样认为的,于是预估5天完成,最后前前后后开发、联调、改bug直到上线差不多花了10天(当然这10天并不是只做这一件事情)。
好好学java
2021/01/07
5100
[926]flashtext:大规模数据清洗的利器
在这篇文章中,我们将介绍一种新的关键字搜索和替换的算法:Flashtext 算法。Flashtext 算法是一个高效的字符搜索和替换算法。该算法的时间复杂度不依赖于搜索或替换的字符的数量。比如,对于一个文档有 N 个字符,和一个有 M 个词的关键词库,那么时间复杂度就是 O(N) 。这个算法比我们一般的正则匹配法快很多,因为正则匹配的时间复杂度是 O(M * N)。这个算法和 Aho Corasick 算法也有一点不同,因为它不匹配子字符串。
周小董
2020/12/29
1.8K0
使用GBDT算法实现敏感词匹配
GBDT(Gradient Boosting Decision Tree)在数据分析和预测中的效果很好。它是一种基于决策树的集成算法。其中Gradient Boosting 是集成方法boosting中的一种算法,通过梯度下降来对新的学习器进行迭代。而GBDT中采用的就是CART决策树。
Lvshen
2024/01/15
5840
使用GBDT算法实现敏感词匹配
日活上百万时,腾讯产品如何提前规避服务器宕机风险?
文章主要讲述了如何利用腾讯云云函数(SCF)和Serverless无服务器架构,实现高性能、低成本、免运维的腾讯云函数计算服务(Tencent Cloud Function,TCF),以及如何通过Serverless架构实现极致弹性、极致伸缩、极致效率,为企业节省成本,提高效率,帮助更多企业快速实现业务价值。同时,文章还介绍了腾讯云云函数(SCF)和Serverless无服务器架构的原理、特点、优势、适用场景、典型客户案例以及如何使用等内容。
WeTest质量开放平台团队
2017/05/15
1.8K0
日活上百万时,腾讯产品如何提前规避服务器宕机风险?
推荐阅读
相关推荐
记一次性能测试的经历
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档