极客时间已完结课程限时免费阅读

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

开篇词丨“老板，之前咱TPS是100，我优化完是10000”-极客时间

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

2019-12-16 高楼 来自北京
《性能测试实战30讲》
课程介绍

讲述：高楼

时长12:10大小11.14M

你好，我是高楼，网名叫 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%，这就是有价值。
希望你可以从实用的角度，理性看待性能市场，而不是人云亦云。 更希望通过这个专栏，你能够在性能领域这条路上坚定地走下去，并获得长足的发展。可以骄傲地说，我的目标是性能工程师，我的职位是性能工程师。
好了，如果你准备好了，那我们就正式开始吧，欢迎你留言说说自己的情况，你心中的性能测试是怎样的？我们下一讲见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 113

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
下一篇
01丨性能综述：性能测试的概念到底是什么？
 写留言

精选留言(68)

  • 一步
    2019-12-17
    看了 老师的开篇，感觉老师是实干派 总体来说就是：别整那么没用的，上测试，出分析，做调优
    共 2 条评论
    46
  • Leo
    2019-12-18
    有全链路压测相关的实战吗？

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

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

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

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

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

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

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

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

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

    共 3 条评论
    14
  • wwwricky
    2019-12-24
    老师，二八原则/响应时间258/TPS拐点 为什么是无用的呢？这个没看懂。

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

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

    作者回复: 多交流。

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

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

    6
  • 琉姩兮珞
    2019-12-23
    听了第一讲，决定入坑学习，哈哈哈

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

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

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

    5
  • jy
    2021-01-25
    答疑区看到老师说：全链路就是系统要做的链路改造。 链路改造是指？

    作者回复: 这话题就大了。像： 1. URL染色； 2. 应用threadlocal改造； 3. 数据影子库； 等等等。

    4
  • 吕作晶
    2020-03-22
    为什么错误的概念却流传更广呢？

    作者回复: 当没有tcpip协议栈的时候，OSI就是王道。 错误的概念流传的原因有多种。我所理解的是： 1，性能测试理念来自于国外。而国外文化跟中国有很大差别。当没有系统理念里，某一个论调被翻译过来，产生理解上的偏差，本来在英语世界里只是一个简单的实验说明。而到了国外却被当成了公理对待。 2，国外也没有完整的性能测试理念。到了国内后，断断续续的信息收集和实际场景被赋予了新的理解。而当初理解的人也只能摸着石头过河。而后来测试领域的发展也没有归整。 3，这些理念看似合理。而在实际工作中没有价值时，只能跟着感觉走。 4，在实际项目中其实并没有人真的按理念执行了。只是先做完应付的工作。 5，由于一些培训机构为了赚钱，进军新领域是比较容易赚钱的方式。而实际上操作时也只能使用已有的信息，导致没成功的理念越传越远。 个人理解，仅供参考。

    共 2 条评论
    4
  • Geek_6a9aeb
    2021-01-22
    如果后续有提供可以方便提供搭建重现性能的瓶颈的环境就好了，期待下个专栏，光听老师的音色就知道是全网最好听的

    作者回复: 性能环境是非常复杂的。不像其他的技术行业，弄一个虚拟机就能跑起来。性能的环境是要一套大环境。所以没办法提供。 你可以自己动手去搭建一个，取决于你有多少的硬件资源。 下个专栏正在码字中。 多谢肯定声音。哈哈。

    共 2 条评论
    3
  • 于文玮
    2020-03-19
    一直做功能测试，一直没有突破，愁人啊

    作者回复: 学习是唯一的突破的途径。

    3
  • 小老鼠
    2019-12-17
    1、性能测试工程师就是全栈工程师喽，真正业内有多少可以达到？2、性能测试工作需要其他人参予吗？3、分布式系统与单机系统在性能上有无差别？若有差别，差別在哪儿？

    作者回复: 1，不一定是一个的需要全栈，一个团队能做到即可，甚至虚拟团队也可以，只要做好项目管理。 2，当然是需要的，主要看性能团队本身能做到什么程度。程度越深，和其他团队的沟通越顺畅。如果连推进性能问题定位分析的能力都没有，那就只能做性能验证了。 3，显然这两者有很大差别。分布式系统首先要做的就是响应时间消耗的监控拆分。定位到某节点后再定向分析。

    3
  • ray
    2019-12-17
    “让性能变得有价值”，让性能测试的价值不再体现在一份份报告上，而是实际提高了多少tps，缩短了多少响应时间，降了多少cpu。最近在做性能测试，一头雾水，工具使用没问题，关键是怎么分析这些数据

    作者回复: 后面的篇幅之中，会有写分析的细节。性能中最核心的就是分析监控数据。而监控数据，又没有一个标准的值。因为环境、业务不同，计数器的值会要求不同，所以只能根据实际场景分析。

    3
  • 善行通
    2019-12-16
    感谢老师分享性能知识，从业务模型到实地开展工作，从基本功夫到工作价值体现，任何理论只有落地才能产生价值，才是有用得理论，不能拿书本中那些理论做对比，咱们从事工作分两方面产生价值，一方面提高效率，一方面提高质量。老师从这两方面下手，解决根本问题，让从事这方面得工作人员展示自己价值。

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

    3
  • 拥抱黑夜的白天
    2020-05-24
    本节课程最大的感悟就是正确认识性能工程师，不仅仅是一个做测试写脚本做参数压测的职业，而是具有更加深刻的意义和价值——能够通过测试的结果进行分析，找到原因得出结论，并且能够给出意见建议来对项目进行调优，使项目的性能得到提升。这需要我们不断的充实自己的业务领域宽度和深度，精确的分析和从业经验不断积累来实现。

    作者回复: 说的非常对呀。

    2
  • 一条好汉
    2019-12-20
    等了好久出来就买了课程，喜欢老师的风格，我也初入性能测试大门，希望学完课程能在调优分析更近一步。

    编辑回复: 如果觉得好的话，帮忙推荐给你身边的朋友

    2