|
|
|
|
|
# 开篇词丨“老板，之前咱TPS是100，我优化完是10000”
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是高楼，网名叫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%，这就是有价值。
|
|
|
|
|
|
|
|
|
|
|
|
希望你可以从实用的角度，理性看待性能市场，而不是人云亦云。 更希望通过这个专栏，你能够在性能领域这条路上坚定地走下去，并获得长足的发展。可以骄傲地说，我的目标是性能工程师，我的职位是性能工程师。
|
|
|
|
|
|
|
|
|
|
|
|
好了，如果你准备好了，那我们就正式开始吧，欢迎你留言说说自己的情况，你心中的性能测试是怎样的？我们下一讲见！
|
|
|
|
|
|
|
