我眼中的性能测试
https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484034&idx=1&sn=e4e5adac098b127bf4f35da34820e3b8&chksm=c0fb14b7f78c9da1f8e17b1304d91fc716762ac2f7004845c91c1d23c99acc3279ac1951b21d&scene=178&cur_album_id=2331539939861282817#rd
笔者专注性能测试的时间大概有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 小结
性能测试是一个庞大而复杂的工程,我们需要以终为始,明确每次性能优化的目标是什么,控制好成本问题,同时需要在平时注意积累各类技术体系,更应当关注技术的底层原理是什么。结合一些常用的分析方法论,快速定位问题。