性能测试必知必会

说到性能测试，咱们究竟是想谈论什么？

任何作产品的，都但愿本身家的产品，品质优，性能好，服务海量用户，还不出问题。

任何使用产品的，都喜欢本身购买的产品功能全，性能优，不花一分冤枉钱。

不过理想很丰满，现实很骨感。实际产品的性能与开发周期，部署方式，软硬件性能等都息息相关。因此真正提到作性能测试的场景，多数是为知足特定需求而进行的度量或调优。

好比：

• 针对交付客户的软硬件环境，提供性能测试报告，证实对客户需求的知足
• 针对特定的性能瓶颈，进行针对性测试，为问题定位提供帮助
• 重大功能迭代，架构设计上线前的性能评估

全部的这些场景，都隐含着对性能测试目标的确认，这一点很是重要。由于若是没有明确的测试目标，为了作而作，多数状况是没有价值的，浪费精力。

而性能测试的目标通常是指望支持的目标用户数量，负载，QPS等等，这些信息通常能够从业务负责人或者产品经理处得到。固然若是有实际的业务数据支持，也能够据此分析得出。因此在开展性能测试以前，必定要先搞清楚测试目标。

目标明确以后，如何开展性能测试？

有了性能测试目标，以后还须要进一步拆解，作到具体可执行。根据经验，我的认为性能测试的执行，最终会落地到如下两个场景：

• 在特定硬件条件，特定部署架构下，测试系统的最大性能表现
• 在相同场景，相同硬件配置下，与竞品比较，与过往分析，总结出优劣

不一样的目的，作事的方式也不同。

第一类场景，由于结果的不肯定性，测试时须要不断的探索测试矩阵，找出尽量优的结果。

第二类场景，首先须要理清楚，业界同类产品，到底比的是什么，相应的测试工具是什么，测试方法是什么。总之要在公平公正的条件下，遵循业界标准，得出测试结果，给出结论。

全部的性能测试场景，都须要有明确的分析与结论，以支持上述两个场景下的目的达成。测试场景要贴近实际的目标场景，测试数据要贴近实际的业务数据，最好就用目标业务场景下的数据来进行性能测试。

服务端性能测试到底要看哪些指标?

不一样的领域，业务形态，可能关注的性能指标是不同的，因此为了表述精确，咱们这里只谈服务端的性能测试指标。

通常咱们会用如下指标来衡量被测业务: QPS, 响应时间(Latency), 成功率，吞吐率，以及服务端的资源利用率(CPU/Memory/IOPS/句柄等)。

不过，这里有一些常识须要明确:

• 响应时间不要用平均值，要用百分值。好比常见的，98值(98th percentile)表示。
• 成功率是性能数据采集标准的前提，在成功率不足的状况下，其余的性能数据是没意义的(固然这时候能够基于失败请求来分析性能瓶颈)。
• 单独说QPS不够精确，而应结合响应时间综合来看。好比 "在响应时间TP98都小于100ms状况下，系统能够达到10000qps" 这才有意义。
• 性能测试必定要持续必定时间，在确保被测业务稳定的状况下，测出的数据才有意义。

要多体会下这些常识，实战中不少新手对这块理解不深，致使有时出的性能数据基本是无效的。

为何性能测试报告必定要给出明确的软硬件配置，以及部署方式？

前面说到，性能数据是与软件版本，硬件配置，部署方式等息息相关的。每一项指标的不一样，得出的数据多是天差万别。因此在作性能测试时，必定要明确这些基础前置条件，且在后期的性能测试报告中，清晰的说明。

jmeter, ab, wrk, lotust, k6 这么多性能测试工具，我应该选择哪一个？

业界性能测试数据工具很是多，不过适用的场景，以及各自特色会有不一样。因此针对不一样的性能测试需求，应当选择合适的性能工具。好比:

• jmeter: 主要提供图形化操做以及录制功能，入门简单，功能也较强大。缺点是须要额外安装。
• ab(apech benchmark): 简单好用，且通常系统内置了，应对简单场景已足够
• lotust：简单好用，支持python编写自定义脚本，支持多worker，图形化界面汇总性能数据。

这里不一一介绍工具，你们有兴趣的均可以自行去网上搜索。

其实笔者在实践过程当中发现，其实绝大多数性能测试场景，都须要编码实现。因此如何优雅的结合现有的测试代码，环境，以及基础设施，来方便的进行性能测试反而是个能够考量的点。

笔者比较承认Go+Prometheus+Kubernetes的模式。首先go语言因其独有的并发模式，上手简单等特色，在云服务，服务端程序领域使用已经很是广了，采用其写脚本，也许与被测程序自然紧密结合。且服务端程序要想很好的运维，必然有一套完整的监控告警体系，而Prometheus基本是其中热度最高的，使用范围最广的，同时咱们也能够将测试程序性能数据打点到Prometheus，这样在计算QPS，成功率等指标上，很是方便。

另外你们知道，在性能测试时，多数须要不断的调整metrix，好比并发数，worker数量等，来探测系统的性能表现，这时候若是将测试程序跑在Kubernetes上，就能够借助其能力，好比Deployment，灵活的部署和水平扩展，体验至关优雅。

单机10000并发为何可能不靠谱？

咱们知道使用goroutine，能够瞬间开不少并发，很是好用。因而可能就会有同窗以为用它作性能测试很方便，直接写个脚本，起超多的并发，去作性能测试。但这样真的靠谱吗？

虽然go语言的并发，经过P，G，M模型，在调度goroutine时，比较高效，但不管如何，任何的程序执行，最终消耗的都是系统资源，测试脚本也一样。因此单机上执行的并发效果，最终会受限于，你脚本的复杂程序，也就是对CPU,IO，网络等系统资源的消耗。因此，并非并发越多越好，必定是基于实际环境，经过不断调节并发数量，worker数量等，来达到最佳姿式。

构建业务性能数据的持续可观测性对产品质量意义重大

一次专项性的性能分析，能够观察当前业务的性能表现，进一步的分析性能瓶颈，为以后的改进提供帮助，意义挺大。但只这样可能不够全面，由于指不定的某次迭代，句柄没关，goutinue泄露，就会形成性能问题，若是咱们没有常态化的检测手段，等上线后才发现，很明显不是咱们想看到的。

因此更优雅的作法是，将性能测试常态化的持续运营，甚至能够作到每次PR触发，都自动执行性能测试，检测性能问题。

To-Be-Continued

性能测试对保障产品质量，提高用户体验意义重大。笔者这里只罗列了一些我的在实际工做中看的问题，以及一些体会，可能不全面。因此若是您有问题，欢迎抛出来，共同探讨。

参考资料

• https://coolshell.cn/articles/17381.html
• https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/
• https://automationrhapsody.com/how-to-do-proper-performance-testing/

Contact me ?

Email: jinsdu@outlook.com

Blog: http://www.cnblogs.com/jinsdu/

Github: https://github.com/CarlJi