性能测试从入门到入土的一点思考
我为什么要写这篇文章
性能测试是软件产品在发布之前必须经过的一个步骤，或在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、安全干货~
上一篇： Numpy库的使用