HTTP 框架 Hertz 实践入门：性能测试指南( 二 ) _框架

连接使用率的估算：如果使用长连接，且连接使用率很高（大部分场景），则使用默认配置即可；如果连接使用率很低，可以添加配置:server.WithIdleTimeout(0)，将 goroutine per connection 的模型修改为协程池模型，并进行对比测试。

数据位置及大小的确定：上面提到不同位置(如 query、header、body 等)及大小的数据对框架可能造成影响，如果所有框架的性能都比较一般，可以考虑换一个数据传输位置。

并发数的确定：有的服务属于轻业务重框架，这个时候框架的并发可能会很高；有的服务属于重业务轻框架，这个时候框架的并发可能会很低。

如果只是想看一下框架的性能，可以使用常规的场景：长连接、较高连接使用率、1k body、100 并发等。hertz-benchmark 仓库默认的压测配置也是如此。同时 hertz-benchmark 仓库也开发给用户 header、body、并发数的配置，用户可以方便的修改这些配置完成贴合自己的压测。
2.1.1 确定压测对象
衡量一个 HTTP 框架的性能需要从两个视角分别去思考：Client 视角与 Server 视角。在大规模的业务架构中，上游 Client 不见得使用的也是下游的框架，而开发者调用的下游服务也同样如此，如果再考虑到 Service Mesh 的情况就更复杂了。
一些压测项目通常会把 Client 和 Server 进程混部进行压测，然后得出整个框架的性能数据，这其实和线上实际运行情况很可能是不符的。
如果要压测 Server，应该给 Client 尽可能多的资源，把 Server 压到极限，反之亦然。如果 Client 和 Server 都只给了 4 核 CPU 进行压测，会导致开发者无法判断最终得出来的性能数据是哪个视角下的，更无法给线上服务做实际的参考。
2.1.2 使用独占 CPU
虽然线上应用通常是多个进程共享 CPU，但在压测场景下，Client 与 Server 进程都处于极端繁忙的状况，此时共享 CPU 会导致大量上下文切换，从而使得数据缺乏可参考性，且容易产生前后很大波动。
所以我们建议是将 Client 与 Server 进程隔离在不同 CPU 或者不同独占机器上进行。如果还想要进一步避免其他进程产生影响，可以再加上 nice -n -20 命令调高压测进程的调度优先级。
另外如果条件允许，相比云平台虚拟机，使用真实物理机会使得测试结果更加严谨与具备可复现性。
3. 性能数据参考
在满足上述要求的前提下，我们基于当前最新版本对多个框架进行了压测对比，压测代码在 hertz-benchmark 仓库。在充分压满 Server 的目标下，Hertz 的 P99 延迟在所有压测框架中最低，吞吐也是属于第一梯队，且在持续优化中。
1.CPU: AMD EPYC 7Y83 64-Core Processor 2.7GHz
1.1运行限定 server 4-CPUs，client 16-CPUs
2.OS：Debian GNU/linux 10 (buster)
3.Go 1.19
4.hertz v0.3.2，fasthttp v1.40.0，gin v1.8.1，fiber v2.38.1

文章插图
四个框架的吞吐和时延比较

文章插图
三个框架的吞吐和时延比较
4. 结语
Hertz 作为一个超大规模企业级的微服务 HTTP 框架，其在设计之初就更倾向于解决大规模微服务场景下的各种问题。在推广过程中也遇到了各种各样的服务，踩了各种各样的坑，也是基于这些服务和遇到的问题写了本文。欢迎广大开发者基于本文提供的测试指南，针对自己的实际场景选择合适的工具。更多问题，请在 GitHub 上提 Issue 交流。
[1] hertz-benchmark: https://github.com/cloudwego/hertz-benchmark

【HTTP 框架 Hertz 实践入门：性能测试指南】