性能测试从入门到入土的一点思考
我为什么要写这篇文章
性能测试是软件产品在发布之前必须经过的一个步骤,或在poc之时,或在uat之前。而不同公司的业务系统千千万,本文将阐述性能测试会被忽略的地方,以及作者在实际性能测试工作期间遇到的问题。希望能对您有一点小小的启发或者帮助。
性能测试工具
我常用的性能测试工具为:
- apache benchmark(ab)
- apache jmeter
- hp loadrunner(lr)(收费)
ab个人认为更适合对纯粹的api接口进行通过率测试,或者仅仅是为了获取tps,简单高效。lr的性能最佳,图表展示好,没有缺点,缺点就是收费(贵不是lr的缺点,是我的缺点)。由于jmeter是开源的,且插件丰富,并发性能刚好满足系统需求,我最终选择了它。
如何确立压测方案
万事开头难,性能测试最难的地方就是如何制定切实有效的测试方案。不同于以往的功能测试,更偏向对于业务的理解。而性能测试,往往想模拟出最真实的实际生产情况下系统会呈现出什么样的问题。
个人如下建议:
- 与系统架构师取的良好沟通,获取整体的系统架构,确立压测的起点(往往一般是从网关开始,但不同的系统又可能有多个业务网关或者对接第三方系统网关)。
2.从业务架构师那获取性能测试的重点,在大数据、微服务大背景下,业务系统往往会被拆分成多个子服务。有的时候为了针对性体现报告数据,有可能会对某些子服务做针对性性能测试(性能不够,数据来凑~)。避免浪费过多精力。
3.及时分析数据,形成报告。
性能测试坑点(干货)
我曾遇到以下坑点(或者说犯的错):
压力测试前并未做基准测试(后来在技术老大的指导下才知道,压力测试必须做基准测试,而且要仿真业务系统实际情况去做基准测试)。
从技术层面上说,压力测试的目标,充分使用硬件资源,把服务器的每个核,能有90%的使用率,说明cpu的性能都使用了(而这点对于开发人员来说,是相反的。就像我们在使用自己的电脑时,cpu占用越低我们越开心,而服务器上理想最佳使用效果就是99%的使用率)。
针对特点业务场景,分清是“计算密集型”还是“i/o密集型”。
日志打印真的很耗时,建议异步写。
个人认为nmon的图表真的不错。
用于压力测试的线程数不宜过多,避免因cpu频繁切换造成额外的性能损耗。
欢迎关注我的公号:彪悍大蓝猫,持续分享大数据、java、安全干货~
上一篇: CentOS7安装高版本gcc
下一篇: 页面响应式布局时,网页图片不缩放