Benchmark（基准测试）初相识

一、benchmark概念

        在计算中，基准是运行一个计算机程序、一组程序或其他操作的行为，以评估一个对象的相对性能，通常是通过对它运行一些标准测试和试验。

        基准测试一词也通常用于精心设计的基准测试程序本身。

基准测试通常与评估计算机硬件的性能特征有关，例如CPU的浮点性能运算性能，但在某些情况下该技术也使用于软件。如，软件基准测试针对编译器或者数据库管理系统（DBMS）运行。

基准测试提供了一种比较不同芯片、系统架构中各种子系统性能的方法。

核心定义：通过设计合理的测试方法，选用合适的测试工具和被测系统，实现对某个特定目标场景的某项性能指标进行定量的和可对比的测试。

二、基准测试的关键点：

• 测试方法：到底使用微基准测试，介基准测试，还是使用宏基准测试，需要根据我们的需要选择一个合适的。
• 测试工具：选择合适的测试工具，能更好的精确的测量出我们的数据。
• 某个目标场景：性能测试时，往往需要选择一些场景。比如到底只是达到某个比较低的标准即可，还是想直接把系统压死等等
• 某项性能指标：需要知道这一次到底追求的是哪个性能指标，到底是QPS还是吞吐量，还是TP99等等。
• 可对比：用不同的方法或者工具进行多次测试进行数据对比

三、测试方法：

（一）微基准测试

        微基准测试(Micro-benchmarks)是基准测试中的一种方法，用来测试微小代码单元的性能，通常这个微小代码单元可以是一段算法，一个方法，一个数据结构。

（二）宏基准测试

        宏基准测试(macro-benchmark)，顾名思义和上面的测试相反，往往会测试一个应用的整体性能，比如模拟大量的真实用户使用这个应用，从而测试出性能。很多时候我们的全链路压测基本就会对应宏基准测试，测试所需要的的流程以及环境都和真实场景一样，这样才能真正的测试出整个应用性能的问题。在真正的全链路压测的情况下，往往会把真实的请求数据先复制下来，然后收集足够多的数据之后，利用这些真实的数据来进行压测。

（三）介基准测试

        宏基准测试对于很多场景比较重，这个时候就出现了介基准测试，介基准测试没有要求请求的真实，在整个链路上一些不是很重要的地方在介基准测试中都可以进行忽略，比如登录验证，安全验证等等，将测试的目标聚焦在我们的业务核心上，通过介基准测试能让我们更简便的测试出系统的性能。

四、测试工具

（一）JMeter

        Apache JMeter是Apache组织开发的基于Java的压力测试工具。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。同时JMeter支持对性能压测结果做图形分析。

        JMeter通常是一个模拟用户就是一个线程，当模拟并发数变多的时候性能会下降，通常会搭建一个JMeter集群去模拟并发数较多的情况。

（二）Gatling

        Gatling是一款基于Scala 开发的高性能服务器性能测试工具，它主要用于对服务器进行负载等测试，并分析和测量服务器的各种性能指标。Gatling主要用于测量基于HTTP的服务器，比如Web应用程序，RESTful服务等。

        Gatling对Java选手来说有一定的学习成本，并且Gatling国内好像使用得较少，但是Gatling使用得Akka Actors异步模型，他可以使用少量的线程就能支持高并发，不需要像JMeter一样搭建多个集群去使用。Gatling在我们公司使用得较多，目前只能测试Http相关的，如果要测试rpc相关的需要先将rpc协议转换成Http协议。

（三）全链路压测PTS/自研

        上面的方法都不能用来做全链路压测，都缺少很多核心功能，比如请求录制，定时压测，实时监控，报告分析等等，这个时候我们可以直接使用阿里云的PTS进行全链路压测，或者自研一套基于自己业务系统的全链路压测系统。

五、性能指标

通常进行基准测试的时候，在结果中会有很多需要值得关注的目标，下面列举一些比较重要的。

（一）QPS/TPS（衡量吞吐量）

        QPS是我们的每秒查询数量，TPS是每秒的事务数量。通常我们进行基准测试往往会定一个目标，比如支撑1000QPS的请求量来完成我们的目标，或者测试出我们这个系统极限的QPS是多少，同样的QPS也不是越大越好，也需要结合我们的响应时间，如果我们一味的追求QPS忽略了响应时间那么用户的体验也是极差的。

（二）TP99/TP95

        有很多认为响应时间应该看平均时间，如果写要求比较低的系统的确是可以看平均时间，这样就会导致很多用户响应的速度很慢，但是我们在监控指标上体现不出来，所以就有了百分位指标这样的概念，TP99的意思就是，取排名排到第99百分位的响应时间，即排除了一些异常的情况（剩余的那1%），又保证了大多数用户的响应时间。（平均响应时间、最小响应时间、最大响应时间、时间百分比等，其中时间百分比参考意义较大，如前95%的请求的最大响应时间。）

（三）CPU（并发量）

        当我们有很多CPU密集型应用的时候，可以多多关注CPU的情况，从而进行针对性的调优

（四）GC

        如果是Java的应用，GC问题绝对不会缺席，尤其是在我们基准测试中，往往如果在测试中出现了大量的GC，说不定是代码写得有问题，有时候可以通过代码进行优化，或者说也可以更换GC收集器。

（五）io

        当我们传输的数据比较多的时候，比如传输文件，或者一些大的数据结构，这个时候就需要关注I/O相关的问题，来进行针对的调优。

六、可对比

可对比同样是基准测试的重要点，通常有下面的几个点：

• 使用不同的测试工具做对比
• 使用不同的测试数据做对比
• 使用不同的测试环境做对比
• 建立长期的基准测试，进行不同时间的基准测试对比。

通常基准测试就是要随时进行测试因子变量的变更，我们才能真正的得到最优的测试结果。

参考：聊聊基准测试 - 云+社区 - 腾讯云 (tencent.com)

【压测】基准测试、性能测试、压力测试--Sysbench_ITPUB博客

https://en.m.wikipedia.org/wiki/Benchmark_(computing)