笔者专注性能测试的时间大概有5年时间，其间也经历了性能测试主流工具从LR到Jmeter转变，监控工具从最早的Linux原生命令到界面花里胡哨的Glances、Zabbix等等。技术架构从单一的节点到多集群，业务对性能的要求越来越高，对于性能测试，有一点小的体会，后续会分多篇来聊聊。今天先说说我对性能测试的一些感观。
友情提醒，文末有福利哦！
01
性能测试的目标
看到这个小标题，大家一定都有很多自己的认知和看法，我会从两个方面进行简单的归纳：技术目标和业务目标。
对于技术目标，大概有4点需要我们去追求和改进的：
- 评估性能，定性分析：这个也是我们做性能的测试的初衷，当我们想要了解某个业务系统的性能状况时，我们会从各类已知的指标入手，常见的有TPS（每秒处理业务数）、ART（响应时间）、系统资源使用率等等。通过技术手段的优化，提升这类指标，给产品以信心，能够应对可能到来的流量洪峰。
- 明确参数配置：我们现在会大量地使用各类中间件、技术组件来解耦我们的系统，其中会涉及大量的参数配置信息。以前一直会有人问“Tomcat的最佳配置参数是多少，XXX参数应该怎么配置才合理呢”这类的问题。本质上，这类问题是没有定值的，需要我们结合业务一起去调整。最典型的，就是线程数的配置，各类中间件大多都有线程数配置，并不是配置越多越好，配置多了，浪费内存，配置少了，增加时间消耗，这个值需要有全局视角，结合业务架构进行统一的配置，否则单节点配置得再高，也不会达到预期值，因为有可能上游就不会有那么多线程流到你的这个节点上来。
- 获取扩展参数，做好预警：做一次好的、完整的性能测试，一定不是简单的给出一个TPS那么简单，对于高阶性能测试，我们都会要求测试出性能拐点在哪里，达到拐点时，瓶颈点是什么。为什么要关注这个呢？因为从高层的角度看，他们更关注的是什么情况下，需要我做扩容，先扩什么东西，以便系统能够撑过流量的高峰，这样对业务才会更有意义。
- 提升各种利用率：这个其实是最后的价值。在以前服务器本成比较昂贵的时候，我们会想办法尽可能的提升服务器的利用率，节约成本。但是现在，伴随着各种云，服务器成本在直线下降，我们面对的是更多业务的不确定性，所以前面三点就变得更加重要，提升利用率反倒显得没那么重要了。不过，如果真的做好前面三点，那利用率自然而然的也会上去，不用特意去纠结。
对于业务目标，主要有两点目标：
- 业务稳定性：这个是我们做性能测试的基本盘，本质上我们做各类测试都是为了维护业务的稳定性，通过性能测试，系统在面对流量洪峰时，能够平稳过渡，是性能测试的最大目标。
- 更好的用户体验：1秒的等待时间和5秒的等待时间，对用户的体验是完全不同的，因此，我们需要提升系统性能，来给用户更好的使用体验，让用户操作更丝滑、更顺畅，提升产品的友好度。
02
技术层面的支撑
性能测试是一个对技术的全面性要求非常高的测试能力，需要从业者具备较广泛的知识体系，能够通过各类监控指标，准确定位到系统瓶颈。所以需要扎实的技术功底，主要有以下三类：
1. 计算机原理：这是很多人都忽略的一件事，现在想要从事性能测试人员，大多数更关注于技术侧的提升，而忽略了最底层计算机原理，实际上这个才是根本，代码的运行，最终还是离不开CPU和内存。建议大家读读《性能之巅》、《深入理解计算机系统》。嗯，这两本书都很容易劝退你，加油。
2. 常见用技术组件：这类组件就非常多了，需要大家结合自己公司的技术架构选型去做针对性的学习，后续有机会展开来讲一些常用的。主要关注的内容是他们的实现原理是什么，如何构建通信通道，常见的错误使用有哪些，如何避免等等，这些网上的资料非常多，需要自己去尝试和验证是否正确。
3. 常见的数据存储组件：以前我们经常会说，性能问题80%出现数据层，对于数据库，我们会非常关注SQL的执行效率。现在的数据存储组件越来越多，Nosql、ES等等，需要大家根据实际需要去做针对性的学习。
03
非技术层面的支撑
除了技术层面的支撑外，为了更好地开展性能测试，我们还需要一些非技术的软技能来支撑日常的工作。主要有两个方面：
1. 分析方法论：面对各种各样的监控指标，我们如何快速地找到对自己有用的信息？一般的性能测试分析方法有分段、分层及二分法。分段和分层比较好理解，在很多地方我们也会用到，比如很多技术框架都提倡分层，每个层专注做自己的事。性能分析也一样，我们可以对被监控系统做好分层，然后逐步定位，缩小范围。
二分法主要用于快速定位并发数，例如当你发现产生1000的并发时，系统已经处理不过来了，这时候你就需要变成500（取1000的一半，看是处到上半部分还是后半部分），然后750（如果在上半部分，就再取一半，以此类推，是不是和排序很像？）。
2. 经济学基础：很多人会好奇做性能测试和经济学有什么关系。举个例子，性能优化，最终还是会回归到是用空间换时间（比如用内存处理数据），还是用时间换空间的问题（上传附件、分页查询）上来，这里面需要做一些动态的平衡，如何做取取舍，是调优时，需要我们去考虑的。
还有一个，就是边际递减问题，大家应该会发现，随着性能测试优化的不断深入，优化越来越难，结果也越来越不明显。前期你可能加个索引，性能就提升了几十倍，但到了后期，你改的代码越多，性能的提升反而不明显。理论上性能测试可以一直进行下去，但实际上后续的优化成本可能会非常高，需要我们在适当的时机停止优化。
04
小结
性能测试是一个庞大而复杂的工程，我们需要以终为始，明确每次性能优化的目标是什么，控制好成本问题，同时需要在平时注意积累各类技术体系，更应当关注技术的底层原理是什么。结合一些常用的分析方法论，快速定位问题。
直播预告
本周三（4月27日）晚9点，约了CC和老张一起聊性能测试体系建设和落地的话题，欢迎大家到时候关注。
