benchmark improvement

As mentioned in the roadmap #13065 , the benchmark construction form I understand is as follows. Do you have any other opinions?

### Dubbo performance benchmark test

#### Goal: Reflect Dubbo’s benchmark performance indicators in all aspects

#### Format: Use the following column chart to compare the performance of a certain scenario (try to keep other parameters the same and pay attention to different parameters), as shown in the following example


#### Scenario 1: request/response

Different rpc frameworks, in the core request scenario (unray) performance, use the commonly used (recommended) configurations of each framework

Parameters/returns use the most common small requests, small returns

| rpc | version (latest version) | protocol | Serialization |
| --------- | ------------- | -------- | ------------- |
| openFeign | 13.0 | http | json |
| grpc | 1.59.2 | grpc | PB |
| dubbo | 2.7.21 | dubbo | hessian2 |
| dubbo | 3.1.11 | triple | hessian2 |
| dubbo | 3.2.7 | triple | fastjson2 |

#### Scenario 2: Serialization method

Dubbo3.2.8 version, small request, small return, using different serialization methods (fastjson2, hessian2, json)

#### Scenario 3: Communication protocol

Dubbo version 3.2.8, small request, small return, using different communication protocols (triple, dubbo, http)
Dubbo version 3.1.8, small request, small return, using different communication protocols (triple, dubbo, http)

#### Scenario 4: Registration Center

Pay attention to the performance of dubbo under different registration centers. Mainly to register rt and push rt

Zookeeper, Nacos, Redis

### Dynamic operation

Similar to the effect of grpc, it is run on the main branch every few hours, and the dashboard is dynamically displayed to monitor the impact of recently merged code on performance.

This item needs to be discussed how to implement it. It can definitely be done by starting a separate service. Is it feasible through CI?

---

### Dubbo性能基准测试

#### 目标：体现Dubbo各方面的基准性能指标

#### 形式：使用以下柱形图，对比某一场景的性能（尽量保持其他参数相同，要关注的参数不同），如下示例


#### 场景1：request/response

不同rpc框架，在核心的request场景（unray）性能表现，使用各框架常用（推荐）配置

参数/返回使用最常见的小请求，小返回

| rpc | version（最新版本） | protocol | Serialization |
| --------- | ------------- | -------- | ------------- |
| openFeign | 13.0 | http | json |
| grpc | 1.59.2 | grpc | PB |
| dubbo | 2.7.21 | dubbo | hessian2 |
| dubbo | 3.1.11 | triple | hessian2 |
| dubbo | 3.2.7 | triple | fastjson2 |

#### 场景2：序列化方式

dubbo3.2.8版本，小请求，小返回，使用不同的序列化方式（fastjson2、hessian2、json）

#### 场景3：通讯协议

dubbo3.2.8版本，小请求，小返回，使用不同的通讯协议（triple、dubbo、http）
dubbo3.1.8版本，小请求，小返回，使用不同的通讯协议（triple、dubbo、http）

#### 场景4：注册中心

关注dubbo 在不同注册中心下性能表现。主要是注册rt，推送rt

Zookeeper、Nacos、Redis

### 动态运行

类似grpc的效果，每几个小时对主分支运行一次，仪表盘动态显示，以监测最近合入的代码对性能的影响。

此项需要讨论如何实现，单独起一个服务必然可以做到，通过CI是否可行？

No files, tests, or entry points are named. Start by reading roadmap issue #13065 and the proposed request/response, serialization, protocol, and registration-center scenarios. Done requires an agreed benchmark implementation, a decision on scheduled CI or a separate service, and a dashboard showing performance changes over time.

Written by the indexing model from the issue text.