共计 956 个字符，预计需要花费 3 分钟才能阅读完成。
我为什么要写这篇文章
性能测试是软件产品在发布之前必须经过的一个步骤，或在 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 频繁切换造成额外的性能损耗。
欢迎关注我的公号：彪悍大蓝猫，持续分享大数据、SpringCloud 干货~
正文完
