有测试驱动的开发模式,目的在于确保业务层面功能是准确的,每一次新增、修改等动作确保都不会影响到现有功能。功能开发完成了,需要部署到线上,系统能够承载多大的用户量呢,这时候就需要借助于性能压测,也称之为压力测试,界定系统能够承载具体容量上限,从容应对业务的运营需要,扩容或缩容,心中有底。
工欲善其事,必先利其器。掌握一种压测工具,并切实应用到实践环境中,并以此不断迭代,压力测试驱动推动所开发后端应用处理性能逐渐完善。
目前成熟的支持支持TCP、HTTP等连接通道的压测工具不少,以前接触过Apache JMeter,后面又接触过Tsung,因为在实际环境下使用比较多,支持丰富的业务场景定义,并且可扩展性强,因此Tsung强力推荐之。
总之,Tsung是一款开源的高性能分布式压力测试工具,支持可编程的情景化测试方案,要向发挥它的特性,依赖于人们的想象力和创造性。
软件/系统架构往往着眼于总体结构,这个可以是一个逐渐完善的过程。这种自我的不断完善的驱动往往来自于实践、线上考验。而压力测试可以提供一种推动,尽心尽力暴露着架构在性能容量存在的一些不足和缺陷,促使着向着更好的方向发展。
系统的构建依赖于具体参与执行的人,就算是一群资深的工程师,业务上每一次功能的快速更迭、任何潜在局部修改都会导致影响、拖垮整体性能,这就是人们常说的 ”蝴蝶效应“,牵一发而动全身。
如何提早感知并且提早修复,这就需要压力测试的驱动,并且压力测试应该成为一个常规化的例行行为,日常化的动作。在每一次修改之后,都要过一轮的压测的碾压之后,提供当前后端应用处理的性能、容量等具体指标,用于指导后续业务上线业务的开展。
在一般互联网公司,一般线上程序修改后之后,需要经过QA团队/部门全部功能回归、校验之后才能够上线,往往缺少压测环节,因为他/她们并不保证系统处理性能和容量是否恶化,系统的性能建立在系统总体的功能上,如何避免在性能上出现”牵一发而动全身“,建议有条件的QA同学/团队考虑增加性能压测环节,功能 + 性能双重回归,修改影响点清晰、透明化。
本系列笔记,基于tsung-1.6.0源码基础上分析,运行环境为Linux Centos 6。
笔记列表:
为了方便理解,一些用词说明:
参与一个实时性交互强的项目,从一开始单机支撑不够1万用户、平均请求响应时间约900毫秒,到目前混合部署的单机支撑50万用户、平均响应时间为16毫秒,这个过程中Tsung不断的压测推动着架构逐渐稳定、系统承载容量、QPS优化等完全达标。这是一个压力测试驱动性能改进的流程,每一步的改进能够得到正向反馈。
这一系列笔记,所谈核心是Tsung,无论是认知还是改进,最终都是为了理解利器的方方面面,方便着手于实践环境中,压测所带来的能量能够驱动我们的程序/服务性能提升、稳定运行,进而更好方便我们进行容量规划、线上部署等。