首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >记一次性能测试的经历

记一次性能测试的经历

作者头像
上帝De助手
发布2019-11-10 22:17:50
7290
发布2019-11-10 22:17:50
举报
文章被收录于专栏:TestQATestQA

近些天由于多接触了些性能业务方面,所以一直在忙项目和加班中,不知不觉中进入了996状态,以至于这两天才得空写写总结。还是希望工作节奏不要这么紧张,毕竟对人的身心都不是件好事。

工作这么多年,一直专注于自动化和工具研发,对性能方面做的相对少很多。主要还是没有实际的上手机会,没有需求就不能很好的实践,光看几本理论知识的书还是不够的。今天主要就来说说这几次性能测试所经历的“坑”。

坑一:测试业务机器准备

首先要说的就是,如果你所在的公司并没有专职的性能测试人员负责性能测试,那么100%的可能情况是:没有性能测试的业务机器。因为没有人会单独留出一部分与线上配置一样的机器空闲在哪里。

另以一方面因为性能测试与自动化测试不同,不是随便搞两台机器能跑起来就行。性能测试为了能准确的评估出线上环境实际的性能表现,测试环境的机器配置需要与线上保持一致,否则压测出的结果很难拿来作为参考依据。

所以这里就可能出现第一个坑:没有符合要求的机器用来搭建性能测试环境。现实情况的就是:临时各种申请和调配,光机器到位就要至少1周时间。

对于那些有专职性能测试工程师的部门和公司,这种情况就会很少见了。

坑二:性能测试环境搭建

即便你等了一个礼拜把机器等来了,那又怎样?还有环境要等着你来搭建呢。再说说现在的微服务“横行”的年代,搭一个服务容易,搭一群你不熟悉的业务环境也就变成“坑”了。而偏偏遇到的性能需求是全链路的性能节点都要关注!

当然了,这里的全链路是指测试环境的全链路,并不是你所想象的阿里们的线上环境全链路。毕竟实现他们那种全链路也是要基础架构提供支持的,不是每个公司都会支持到这种程度。

如果你比较幸运,对于要做性能测试的业务比较熟悉,那么环境可能自己就能搞定。现实情况却是:让开发帮忙搭了一天,才算把部分环境调通,暂时可以进行阶段性的性能测试。

可以这么说:搭环境是性能测试里,最不想做的事情,没有之一!

坑三:性能测试环境配置

好不容易把环境搭建起来,跑了一波性能测试数据,检查的时候却发现“数据量”对不齐。发了300w的量却只消费了100w,刚开始还以为程序有问题,再后来还以为kafka有积压,最后才知道是kafka配置跟线上不一致。

所以这里要长个“心眼”,除了机器配置、软件配置跟线上一致,基础服务的资源和配置也要跟线上保持一致,否则很有可能出现一些“意想不到”的状况。

当然了,这个“坑”是专属于性能新手的,老手基本上都被坑过千万遍了,很难在入“坑”。

坑四:性能测试数据准备

还是回到“故事”的源头,如果你身在一个性能测试较为成熟的公司,那么数据准备可能不是什么事情。比如:准确的峰值数据、真实的请求比例以及真实的请求数据。都可能很容易的评估和获取到。

否则,你可能需要费点劲来评估数据和生产数据。评估基本靠猜,数据基本靠造。压测完了数据到时有,只是到底准不准,只有上天知道。

不过话说回来,评估这种事情如果没有历史数据作为参考,也就只能猜了。不然你以为所谓的“人工智能”是怎么算出来的。只是有些数据如果能方便的从线上拉去日志,这个“坑”就可以填上一大半了。

坑五:性能测试压测平台

这个“坑”本来不想入,但是却没有别的办法。因为这个基础平台不用的话,也没有资源去跑压测服务,也没有好的办法发去收集系统资源信息。只能说基础压测能力是有了,但是离全流程的性能支持还差那么一半。

简单列一下平台的几个“坑点”:

•不能单个请求调试•没有检查点支持•需要执行一段时间才能出结果•不能看日志,即使有错误也看不到

大厂的话这些基础平台的能力应该要稍微健全点,小店的话自己有权限胡乱造,只有“中不溜”的才有这种情况。

坑六:性能测试资源监控

资源监控在性能测试中也算是比较重要的,但是由于性能平台的限制,只能关联监控一台服务器,不能满足多个服务同时监控的需求。

还好可以从运维平台单独打开多个页面来查看,只不过后期整理的时候,你想要的图得一个个自己慢慢整理。所以这个“坑”还好,不算太大。

坑七:性能测试瓶颈分析

性能瓶颈分析是最让大家津津乐道的,毕竟还是有很多“神学”在里面。刚学习性能的时候,告诉你的各种套路,当你在实践时发现一个都用不少。因为你会发现没有性能瓶颈,至少是没有明显的性能瓶颈。

最常见的情况可能不是一上压力,CPU、内存、磁盘就狂狂飙升;而是换成了“风平浪静”的场景,最多稍微有点“小高潮”就到顶了。新手遇到这种情况一般都是懵逼的,尤其是你还可能拿不到各种日志、各种资源监控的情况。

具体的性能分析方法,等攒够了经验系统化后,再出个性能分析的系列篇。这里先说说我遇到的性能瓶颈的“坑”。

•mysql慢查询。最大的坑,没有之一•日志输出太多。debug的锅•中间件。都是共用基础服务惹的祸•带宽。超大body体的请求需要注意•压力上不去。生产端还能再快点么

坑八:线上实际效果分析

压测的时候以预估的量,结果预估的量太大了,导致没有足够的压测机器,只能等比例压测机器。本来还担心等比增加后会,线上全量性能效果会不会打折扣,结果让人大跌眼镜的是线上实际量远小于预估量。

当然,说实话也怪不了别人,头一次做大促难免有点拿捏不住。毕竟即没有历史数据参考,也没有很好的用户行为模型分析。说压多少量就压多少量,其它的咋也不敢说,咋也不敢问。

总结

多做几次性能项目后,你就会发现性能和功能都是一样的套路 -- 熟练工种。那些坑都填过后,以后再走就是平道了。性能分析也没有那么神乎其神的,那些一眼就能看出毛病的人基本都是被坑的多了才长的心眼。

要增强性能分析能力,还要具备很好的系统基础知识、对业务的熟悉、对架构的理解,另外还有必不可少的实(入)践(坑)经验。如果脱离了这些,光拿几个曲线图就能给你分析出个所以然来的,不是神棍就是骗子。

80%的时间用在前期环境和数据准备上面,压测就用一小会,性能瓶颈的分析占用后面的20%的时间。这个比例在我这来看一点都不夸张。

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

本文分享自 TestQA 微信公众号,前往查看

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 坑一:测试业务机器准备
  • 坑二:性能测试环境搭建
  • 坑三:性能测试环境配置
  • 坑四:性能测试数据准备
  • 坑五:性能测试压测平台
  • 坑六:性能测试资源监控
  • 坑七:性能测试瓶颈分析
  • 坑八:线上实际效果分析
  • 总结
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档