性能测试从入门到入土的一点思考

我为何要写这篇文章

性能测试是软件产品在发布以前必须通过的一个步骤，或在POC之时，或在UAT以前。而不一样公司的业务系统千千万，本文将阐述性能测试会被忽略的地方，以及做者在实际性能测试工做期间遇到的问题。但愿能对您有一点小小的启发或者帮助。

性能测试工具

我经常使用的性能测试工具为：

• Apache Benchmark（AB）
• Apache JMeter
• HP LoadRunner（LR）（收费）

AB我的认为更适合对纯粹的api接口进行经过率测试，或者仅仅是为了获取TPS，简单高效。LR的性能最佳，图表展现好，没有缺点，缺点就是收费（贵不是LR的缺点，是个人缺点）。因为JMeter是开源的，且插件丰富，并发性能恰好知足系统需求，我最终选择了它。

如何确立压测方案

万事开头难，性能测试最难的地方就是如何制定切实有效的测试方案。不一样于以往的功能测试，更偏向对于业务的理解。而性能测试，每每想模拟出最真实的实际生产状况下系统会呈现出什么样的问题。

我的以下建议：

1. 与系统架构师取的良好沟通，获取总体的系统架构，确立压测的起点（每每通常是从网关开始，但不一样的系统又可能有多个业务网关或者对接第三方系统网关）。

2.从业务架构师那获取性能测试的重点，在大数据、微服务大背景下，业务系统每每会被拆分红多个子服务。有的时候为了针对性体现报告数据，有可能会对某些子服务作针对性性能测试（性能不够，数据来凑~）。避免浪费过多精力。

3.及时分析数据，造成报告。

性能测试坑点（干货）

我曾遇到如下坑点（或者说犯的错）：

1. 压力测试前并未作基准测试（后来在技术老大的指导下才知道，压力测试必须作基准测试，并且要仿真业务系统实际状况去作基准测试）。
2. 从技术层面上说，压力测试的目标，充分使用硬件资源，把服务器的每一个核，能有90%的使用率，说明CPU的性能都使用了（而这点对于开发人员来讲，是相反的。就像咱们在使用本身的电脑时，cpu占用越低咱们越开心，而服务器上理想最佳使用效果就是99%的使用率）。
3. 针对特色业务场景，分清是“计算密集型”仍是“I/O密集型”。
4. 日志打印真的很耗时，建议异步写。
5. 我的认为nmon的图表真的不错。
6. 用于压力测试的线程数不宜过多，避免因CPU频繁切换形成额外的性能损耗。

欢迎关注个人公号：彪悍大蓝猫，持续分享大数据、SpringCloud干货~