高楼的性能工程实战课 / 搭建完整项目,真刀真枪实践性能测试

高楼
盾山科技CEO,7DGroup创始人
  • 课程目录
  • 课程介绍
  • 开篇词 | 打破四大认知局限,进阶高级性能工程师

    把性能从“测试”引到“工程”的级别,只有这样,才是一个性能项目的真正价值可以体现的方式。

  • 01 | 性能工程:为什么很多性能测试人员无法对性能结果负责?

    请不要拿着“工程”的幌子干“测试”的事情,也不要把工程说得飘在天上。只说一大堆原理,却没有一个落地的过程,那是耍流氓。

  • 02 | 关键概念:性能指标和场景的确定

    说到性能需求,真是我从业十几年来性能职场辛酸的起点。因为我几乎没有见过精准明确的需求,很多时候性能需求都变成了一句空话。

  • 03 | 核心分析逻辑:所有的性能分析,靠这七步都能搞定

    我们的宗旨就是,把性能分析思路给固定下来。是的,你没有看错,我说的是“固定”下来。

  • 04 | 如何构建性能分析决策树和查找瓶颈证据链?

    请你记住一点,用什么监控工具并不重要,有没有监控到全部的计数器才重要。

  • 05 | 性能方案:你的方案是否还停留在形式上?

    在性能市场上,有太多的性能方案是抄来抄去的,总体的结构大同小异。这也就导致了在性能项目中,大量的方案都只有形式上的意义。

  • 06 | 如何抽取出符合真实业务场景的业务模型?

    我们在做场景时首先要明白,当前的场景是要模拟历史业务场景,还是未来业务场景。

  • 07 | 性能场景的数据到底应该做成什么样子?

    经常有人拿着少得可怜的数据,来做比较大的压力,这显然不符合真实场景,虽然拿到的结果很好看,但并不会得到什么有价值的结果。

  • 08 | 并发、在线和TPS到底是什么关系?

    Session仅仅是消耗着保存字符串的那部分内存,来做用户和系统之间的识别,并不能用来做性能中的并发用户数计算。

  • 09 | 如何设计全局和定向监控策略?

    性能监控数据不足带来的问题就是没有分析的证据链。从现象到结论,如果没有完整的分析链路,那就是在连蒙带猜做性能。

  • 10 | 设计基准场景需要注意哪些关键点?

    如果你做完了一个项目,却不能告诉对方这个系统能不能好好活着,那人家还要你干嘛,直接砍掉这个项目就好,还省了成本。

  • 11 | 打开首页之一:一个案例,带你搞懂基础硬件设施的性能问题

    如果你是从零开始做一个完整的项目,那么这些问题很可能是你首先要去面对的。并且把它们解决好,是性能分析人员必备的一种能力。

  • 12 | 打开首页之二:如何平衡利用硬件资源?

    资源均衡使用非常容易被忽略,可是它极为重要。我们通常都盯着计数器给出的数值有什么异常,而不是考虑资源怎么做相应的调配。

  • 13 | 用户登录:怎么判断线程中的Block原因?

    登录功能实际上会涉及到很多的业务,它其实一点也不简单。

  • 14 | 用户信息查询:如何解决网络软中断瓶颈问题?

    在很多性能项目中,很多人都无法将软中断跟响应时间慢和TPS所受到的影响关联起来。

  • 15 | 查询商品:资源不足有哪些性能表现?

    不要轻易给出资源不足的结论。因为但凡有优化的空间,我们都要尝试做优化,而不是直接告诉客户加资源。

  • 16 | 商品加入购物车:SQL优化和压力工具中的参数分析

    这节课我会教你怎么根据资源使用率高,快速定位到有问题的SQL,并做出相应的调整。

  • 17 | 查询购物车:为什么铺底参数一定要符合真实业务特性?

    我们虽说是做性能分析的人,但也不是只分析性能问题,而是见到问题就要去解决,要不然,你就走不下去。

  • 18 | 购物车信息确定订单:为什么动态参数化逻辑非常重要?

    在所有的性能场景中,使用的资源都应该按真实发生的业务逻辑来确定,有且只有这样,才能保证结果是有效的。

  • 19 | 生成订单信息之一:应用JDBC池优化和内存溢出分析

    当批量业务和实时业务同时出现在同一个数据库中,并且是对同样的表进行操作,这时,你就得考虑一下架构设计是否合理了。

  • 20 | 生成订单信息之二:业务逻辑复杂,怎么做性能优化?

    我们在性能环境中做优化,把资源用起来是为了看系统的最大容量在哪里。这并不意味着,你可以在生产环境中让硬件使用到这种程度。

  • 21 | 支付前查询订单列表:如何分析优化一个固定的技术组件?

    对于一个非常成熟的固定组件,我们要想优化它,就要去了解它的架构,找到它的相关性能参数。

  • 22 | 支付订单信息:如何高效解决for循环产生的内存溢出?

    对于Java的应用来说,我们要把内存的溢出找出来,就必须理清楚代码的逻辑,知道哪个变量在哪里定义,层级关系也要划分清楚。

  • 23 | 决定容量场景成败的关键因素有哪些?

    在容量场景中,业务模型一定要覆盖生产环境中的业务峰值,并且还要覆盖生产环境中的最大资源使用率峰值。

  • 24 | 容量场景之一:索引优化和Kubernetes资源分配不均衡怎么办?

    做容量场景的目的是要回答“线上容量最大能达到多少”的问题,这就要求我们在设计和执行容量场景的时候要非常严谨。

  • 25 | 容量场景之二:缓存对性能会有什么样的影响?

    你有没有听过性能行业中一直流传的一句话:性能优化是无止境的。所以,我们一定要选择好性能项目结束的关键点。

  • 26 | 稳定性场景之一:怎样搞定业务积累量产生的瓶颈问题?

    在稳定性运行之前,一定要想好监控哪些计数器,避免在稳定性运行过程中遇到问题时,发现没有可用的计数器分析问题,那就悲催了。

  • 27 | 稳定性场景之二:怎样搞定磁盘不足产生的瓶颈问题?

    磁盘不足的问题在稳定性中也是经常出现的。因此,我们在稳定性场景运行之前,最好预估一下会用到多少磁盘。

  • 28 | 如何确定异常场景的范围和设计逻辑?

    在性能的领域中,异常场景一直都处在薄弱的环节,大家都觉得异常场景应该做,但是又不知道怎么做才能把异常问题覆盖全面。

  • 29 | 异常场景:如何模拟不同组件层级的异常?

    我们在判断异常场景的范围和设计异常场景的时候,还是要注意把整个架构中的所有层级的组件都覆盖全,不能遗漏。

  • 我们这个课程的系统是怎么搭建起来的?

    我们当时在分析 OpenStack 本身的问题上花费了很多时间,对于我们的这个系统来说,这是没有必要的。

  • 30 | 如何确定生产系统配置?

    在我看来,应该由性能团队给出生产环境中的性能参数配置,这是最为合理的

  • 31 | 怎么写出有价值的性能报告?

    性能报告也一样,“三分干活七分报告”,也就是说干活的辛苦都是留给自己体会的,报告如果做得不好,你所有的付出都会付诸东流。

  • 一套习题,测出你的掌握程度

    这套测试题共有11道单选题和9道多选题,满分100,核心考点都出自前面讲到的所有重要知识。

  • 结束语 | 做真正的性能项目

    性能给出业务容量的保证,才是真正的价值体现。

【立省 ¥40丨仅限前 50 人】

拼团+口令「xingneng9」立省 ¥40 仅限前 50 人

*订阅后凭支付截图,可加入高楼老师性能工程交流群

你将获得

  • 基于一个真实项目的性能分析策略
  • 打破性能分析四大错误认知
  • 深入剖析影响性能结果的五个环节
  • 四大性能场景高手设计思路

讲师介绍

高楼,网名Zee,性能专家,盾山科技CEO,7DGroup创始人 ,性能标准撰写人,《性能测试实战30讲》专栏作者。性能领域公认的具有匠心的技术专家,架构级性能解决方案资源专家。

高楼拥有14年性能测试分析调优经验,致力于架构级性能测试、容量水位规划、性能瓶颈分析、性能异常等技术方向。强调性能测试之后的调优过程,致力于将性能测试与分析的结果在生产环境中体现。

课程介绍

作为一个性能工程师或是性能团队负责人,你是否敢拍着胸脯说:“这个系统‘死’了我负责!我卷铺盖就走人!”如果你敢这样说,得到的工资肯定是不一样的。可是,在当前的性能市场中,有谁敢给这样的业务保证呢?

在很多人看来,性能测试仅仅只是“测试”,很多性能团队也只是找找基本的技术瓶颈。错误理念或乱象在这个行业中大行其道,比如说:

  • 过于关注性能中的某些工具;
  • 只浮于理论层面,不知道具体的落地过程;
  • 遇到性能瓶颈,拿不出证明瓶颈根本原因的证据,甚至被开发或运维像皮球一样踢来踢去;
  • 工作结果无法体现到业务场面,无法对系统上线后的状况作出准确预判;
  • ……

基于这样的市场现状,我希望通过这个课程将性能分析的真正价值体现出来,改变你原有的一些错误认知,帮助你在性能这条路上走得更深、更远。这就需要我们把性能从“测试”引到“工程”的级别,因为只有这样,才是一个性能项目的真正价值可以体现的方式。

为了能让你更好地理解这些内容,我专门搭建了一个完整的系统,我在这个系统中遇到的性能问题,以及我的分析过程都将在这个课程中呈现出来,你看到我所讲的分析方法和路径都是能够一一落地的。

我希望你能看到一个性能项目真实的落地过程,知道在一个性能项目的各个阶段应该做什么事情以及要做到什么样子,从一个更为宏观、全局的视角,真正吃透性能,同时知道这个方向其实可以干很多事情。

在这个课程中,我将整个性能工程的内容分为以下五个模块给你讲解:

第一部分,性能工程的核心理念。

在这部分,我会对当前的常见的性能项目中的实施过程进行解析,分析常见的问题,并给出相应的解决方案。性能在国内也有几十年的时间了,而很多人对性能的误解还是很深。像“性能测试项目到底应不应该做瓶颈定位分析”等常见的争论一直都存在,而这部分内容就是要给你说明,性能工程中必须要有的理念。

第二部分,性能工程的实践关键点。

这部分是RESAR性能工程的核心,我会对性能项目中几个重要的环节进行详细的说明,比如说业务模型抽取、参数化数据、性能监控等。在性能项目中,这里面的每个环节都直接决定项目的成败。

第三部分,基准场景。

在性能领域中,有一个声音已经响了多年:“基准场景就是拿几个用户试跑一下,验证场景、脚本、数据的正确性。”我觉得那只是场景验证而已,并不符合基准场景应该有的定义。

而在RESAR性能工程中,我将基准场景定义为把单业务测试到最大TPS的场景。在基准场景中,你将看到很多性能瓶颈,这些瓶颈在基准场景中的分析相对简单一些。不过,请你记住,基准场景是非常重要的。

第四部分,容量/稳定性/异常场景。

在RESAR性能工程中,只有四类场景。第四部分我将为你呈现其他三类场景:容量场景、稳定性场景和异常场景。

容量场景是最应该符合生产环境业务场景的,容量场景要获得系统最大的TPS,有了这个结果才能知道生产环境能不能支持得住最大的业务容量;稳定性场景是为了考验系统的长时间运行能力;异常场景是为了考验系统面对异常问题时的处理能力。

第五部分,性能结论。

性能项目最重要的就是结论。在这部分,我将为你说明性能报告如何编写,同时也将告诉你性能项目完成之后,如何给出运维需要的配置建议。因为对于性能来说,如果仅是在测试环境中给个结论、找些明显的Bug是远远不够的,这只是工作的一部分,能给出生产环境运行的建议和容量才是关键。

课程目录

特别放送