性能测试实战 30 讲
高楼
前 HP 高级性能专家,7DGroup 创始人
45941 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 37 讲
性能测试实战 30 讲
15
15
1.0x
00:00/12:10
登录|注册

开篇词丨“老板,之前咱TPS是100,我优化完是10000”

讲述:高楼大小:11.14M时长:12:10
性能工程师的前景
学习性能测试的方法
性能工程师的价值
性能测试的含义和工作内容
作者介绍
性能测试专栏知识关系脑图

该思维导图由 AI 生成,仅供参考

你好,我是高楼,网名叫 Zee。 很高兴能在这里和你聊性能测试。
在课程开始之前,我先介绍下我自己的从业经历。
从 2005 年毕业开始,除了第一年在做路由器方面的功能、性能测试之外,我后面的工作几乎都是围绕着性能测试分析展开的。
那时我还年轻,喜欢混迹于各大测试论坛,从而认识了很多行业内的高手,很多人也是从那里认识我的。再后来我开始自己弄测试论坛,其实主要是将自己在工作中的积攒的经验分享了出去,虽然一直没有商业化运营,但是不得不说,这个过程对我的知识体系积累起到了非常重要的作用。渐渐地,我用这个论坛形成了自己关于性能测试完整的知识链。
再后来,我开始带团队,我做性能项目的宗旨就是上线不死,死了不收钱。
我从四五个人的小团队开始,一直到有 300 余人的国内外混合团队。我带着这些团队,完整地做过大概 40 多个项目。你可能会问,“完整的项目”是什么意思?它指的就是持续时间在 2 个月左右的性能项目。
为什么会耗时这么长呢?这就涉及到了性能测试的真正含义和工作内容。
我一开始也和大多数人一样,以为做性能测试,就是做些脚本、参数化、关联,压起来之后,再扔出一个结果。
随着时间的增长,我越做越多。慢慢地,我发现,性能测试好像远不止这些内容。
当我把性能分析也加入到工作中之后,性能工作一下子变得丰富起来。现在,我更关注一个性能测试项目在分析调优了之后,响应时间有多大的提升,TPS 有多大的提高,资源有多少的节省。
我曾经在一个零售业大厂做过一个性能咨询。他们的硬件资源很多,256C512G 的机器有一堆,在生产环境中,几乎没有把 CPU 用得超过 5% 的,但是性能问题还不断出现。后来经过两周的性能分析,最后把硬件降到了原来的四分之一,但同时又把性能提高了 10 倍,降硬件的同时,性能也提高了。
类似的工作还有很多,正是这些经历让我觉得,在一个性能测试项目中,分析是必然的过程,只有这样,性能测试的工作才有落地的价值。而这个过程,最好是性能工程师来做,不是别人,因为只有性能工程师才可以串起完整的链路
真正的性能工程师,可以把结果整理清楚之后,又可以下结论,提出解决方案:线上根据这个测试结果,做对应的配置,系统肯定可以稳定运行。又或者是这样的:当前测试说明了线上不能支持,后面应该如何优化。
你看,这样做,性能工程师的价值是不是立刻就显现出来了?
所以,我们努力的方向是性能的完整工程,这就是我在开头提到的,既要有前期的测试,还要有中间的分析,以及最后的调优,而不仅仅是做做脚本。
当然了,做脚本和参数、压场景、出报告,这是所有新手都必经的一个过程,就像写代码先从“Hello World”开始一样。但是这个过程,必然要在短时间内渡过。
如果你想把性能测试做好,就不要局限自己的技术范围和认知范围。无论是系统、数据库、代码、中间件、存储、网络,你遇到什么问题,都要试着去分析下该如何判断,并考虑如何在后续的过程中进行调优。
在此我需要强调一下,也希望借此可以纠正你的认知,那就是,在我们这个课程中,“性能测试”不仅仅包括测试,还包括分析和调优

学习性能测试的方法到底是什么?

那现在你心里是不是有个问题:好,我知道了这些,但是到底怎样才能做到呢?
在性能行业中,我看到很多人还在拿着一些看似合理实际没用的概念套在当前的性能领域中。
比如说,性能策略中的性能测试、压力测试、衰减测试、配置测试等等。这些概念你可能听了不下百遍了,但如果问你,你在项目中是否用到了这些策略?估计你都不大能想得起来,自己做的某个场景用到过什么样的策略。
比如说“二八原则”、“响应时间 258 或 2510”、“理发店模型”、“最大 TPS 拐点”等等指标类的紧箍咒。在我看来,在项目的实践中,它们不只是百无一用,而且还产生了错误的导向。
因此,针对当前性能行业的现状,我结合自己多年来的经验,写了这个专栏。在专栏中,我将以实际的项目经历,告诉你在一个具体的项目是如何一步步落实到性能领域的每一个环节中的。
那这个专栏是怎么组织的呢?我主要分了四个模块。
第一个模块是性能测试基础篇。我想在这个模块里澄清一些性能测试的基础概念,讲解一些关键部分。但并不是对概念的简单描述,而是根据实际项目,告诉你真正具有指导价值的性能测试概念是什么,并解析这些概念在实际操作中的指导性作用。
在第二个模块中,我将通过性能测试工具的实际操作实例,对应性能测试的前后逻辑关系。在这一部分中,我会重点给你讲解,为什么要使用某些工具的某些功能,以便确保工具的使用及结果是为性能测试需求指标和性能分析报告而服务的,而不是浮于表面的“炫技”。
在第三个模块中,我将通过操作系统、应用服务器、数据库、缓存服务器、Java、C++ 等监控工具的使用和分析方法,告诉你它们产生的数据在性能分析过程中该如何判断,为测试报告及性能分析提供有效的历史数据。
最后一个模块是对前三个模块的凝练,我会讲解不同实际操作场景中的性能测试分析过程,比如实际的瓶颈判断的过程是怎样的,怎么分析出根本的原因,如何提出具体的解决方案,最后的实施效果又是怎样的。
总的来说,这门课我自己有一个原则,那就是:我不想用空中楼阁似的理论获得情感上的激情,也不想用未经实践的过程获得短暂认同。

性能工程师的前景到底在哪里?

看到这里,如果你已经跃跃欲试想要一探性能测试分析的究竟了,热烈欢迎你。不过我还是有些心里话要再唠叨几句。
性能领域要求的专业技能并不少,发展的宽度和深度完全取决于你自己的意愿。你可以选择只做一个写脚本的工程师,也可以选择成为一个性能调优的专家。从技术范围上说,测试工具、操作系统、开发语言、实现架构、数据库、网络、存储、部署架构等,都是你需要掌握的内容。
所以,我希望这个专栏可以抛出一个价值观——让性能变得有价值。以此刷新你对性能测试的认识,知道这个方向可以干很多事情。
那价值体现在哪里呢?
在性能测试分析优化之前,如果 TPS 是 100,你做完了之后 TPS 是 10000,这就是价值。
在性能测试分析优化之前,如果响应时间是 0.1ms,你做完了之后是 0.01ms,这就是有价值。
在性能测试分析优化之前,如果 CPU 使用率是 100%,你做完了之后是 50%,这就是有价值。
希望你可以从实用的角度,理性看待性能市场,而不是人云亦云。 更希望通过这个专栏,你能够在性能领域这条路上坚定地走下去,并获得长足的发展。可以骄傲地说,我的目标是性能工程师,我的职位是性能工程师。
好了,如果你准备好了,那我们就正式开始吧,欢迎你留言说说自己的情况,你心中的性能测试是怎样的?我们下一讲见!
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章主要介绍了作者Zee在性能测试领域的从业经历和见解。他强调了性能测试不仅包括测试,还包括分析和调优,并分享了自己的实践经验和对性能工程师的展望。文章分为四个模块,分别介绍了性能测试的基础概念、性能测试工具的实际操作、监控工具的使用和分析方法,以及实际操作场景中的性能测试分析过程。作者希望通过这篇文章,让读者能够理性看待性能市场,坚定地走在性能领域的路上,并获得长足的发展。文章内容丰富,涵盖了性能测试的方方面面,对于想要了解性能测试领域的读者具有很高的参考价值。

2019-12-16129人觉得很赞给文章提建议

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《性能测试实战 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(69)

  • 最新
  • 精选
  • Leo
    有全链路压测相关的实战吗?

    作者回复: 这个话题说大不大说小不小,在这个专栏中,我没打算讲全链路压测相关的话题。 不过既然这里问到,我大概描述一下我不打算写的原因。 全链路压测是两个部分。全链路 和 压测,压测部分要做的就是有清晰的标识,而全链路就是系统要做的链路改造。 从技术层面说,不管是使用同样的硬件做旁路应用,还是改造已有应用做链路标识识别,技术的实现手段都是成熟的。 我最近在设计一个全链路压测的模拟系统,开发很快就能做得出来。 但是全链路的难点在系统的庞杂和团队之间合作的推进。所以全链路是个管理协调的难度大于技术实现的事情,并不像很多人所说的那么高高在上。

    2019-12-18
    3
    34
  • 技术修行者
    现在带一个最近在带一个小团队做项目的底层框架设计,为业务提供基础服务。 业务端的性能测试人员的套路就是写脚本+跑压测+贴结果,没有任何分析,直接发给所有人。因为给出的只是全链路的结果,我只能是把它分成不同的部分,例如前端、业务服务、基础服务等,然后分析瓶颈到底是什么原因造成的。 因为基础框架提供了数据访问服务,压测过程中发现用户到达一定规模后,某个业务相应操作时间在1分钟以上,所有人都指向了基础服务做的不好,影响了团队的士气,于是我做了一系列操作,抓取日志、分析日志,发现业务使用的SQL语句,在极端情况下,在dn客户端也需要执行1分钟以上才能返回结果,和基础服务没有关系,又是一通撕。。。 作者的专栏立意很好,希望能学完这个专栏后,更好的应对可能出现的各种性能问题。

    作者回复: 你说的这个场景。我也见过很多。 一看就是有实际的工作经历的。 性能的价值的具体体现,在你说的这个点上就非常非常重要。要是性能团队能直接说哪个环节上哪个代码段哪个配置哪个sql有问题,不仅可以减少沟通成本,体现性能的价值,也会得到其他技术团队的尊重。

    2020-01-01
    23
  • zuozewei
    性能测试通过概念、模型、观测、实验等手段来进行问题的剖析。其涉及范围之广,从压力工具、操作系统、开发语言、数据库、消息队列、中间件、网络、压力工具等各个方面。通常还需要深入的理解各种原理,特别是在一些重点细节上,往往需要有超出一般的认识和方法。

    作者回复: 深得真传呀。哈哈。

    2019-12-16
    3
    19
  • 斜月浮云
    老板说,小伙子写的代码太差了,浪费了硬件99%的性能,太败家了,还得专门花时间优化才能上线😂

    作者回复: 哈哈,要没有写代码差的小伙给我们提供更多工作内容,我们的价值体现就要少一部分了。

    2019-12-17
    2
    17
  • David.cui
    我是一个DBA,在某个金融客户的上线之前的压力测试中,tps可以到8000多,但是cpu使用率达80~90%。客户联系我到现场之后,发现大量的cpu资源都是sys%部分。我们经过反复测试发现数据库的参数没有问题,是操作系统架构需要调整,调整之后 cpu使用率不到50%,tps达到了10000+

    作者回复: 那真是太棒的优化结论了。为你点赞。

    2020-01-27
    4
    15
  • wwwricky
    老师,二八原则/响应时间258/TPS拐点 为什么是无用的呢?这个没看懂。

    作者回复: 后面篇幅中会有说为什么它是无用的。在这里稍做解释。 二八原则,做为一个宏观经济学的统计结论,它对一个特定的性能项目并没有实际的参考价值。因为一个项目中用户的高峰周期完全取决于业务的特性,当没有分析业务而直接使用二八原则来套路,基本上都会和实际的系统有较大偏差。 响应时间258这个已经在后面的篇幅中解释的很清楚了,它做为古老的音频缓冲统计数据,对现在的业务应用基本上没有参考价值,技术的发展和业务的特点对响应时间的要求会更会具体。 TPS拐点之所以说无用是因为在很多系统中,拐点都不是明确出现的,TPS是缓慢上升的,有弧度的,而不是有明确拐点的。

    2019-12-24
    8
  • 月半虫工🍧
    一直想学性能测试,但靠看书自学完全入不了门,希望老师能带我入门。我也会坚持做笔记,下面是我的幕布笔记链接:https://mubu.com/doc/dL5rtL432Z

    作者回复: 多交流。

    2019-12-18
    2
    7
  • Beluga
    最初写php,今年在写java,最近负责公司业务的性能测试。性能调优比写代码更有趣,当通过自己的实践让tps,响应时间的提高,避免错误率。有种玩游戏闯关的感觉。

    作者回复: 非常对呀。我也经常有这种玩游戏时拿钥匙的感觉。哈哈。

    2020-05-13
    6
  • 琉姩兮珞
    听了第一讲,决定入坑学习,哈哈哈

    作者回复: 入坑才发现坑是填不满的。从此人生进入另一填坑阶段。

    2019-12-23
    2
    6
  • bolo
    想通过学习性能测试的时候, 把相关的技术栈补一补。 目前停留在“做脚本和参数、压场景、出报告”的地方,想向前走一走.....

    作者回复: 树挪死,人挪活。 总得往前走一步,才能不断进步。

    2019-12-24
    5
收起评论
显示
设置
留言
69
收藏
99+
沉浸
阅读
分享
手机端
快捷键
回顶部