lizining1231 commented on PR #3706:
URL: https://github.com/apache/dubbo-go/pull/3706#issuecomment-5440264142
CI的集成测试错误排查如下：
非偶发错误，仅该PR稳定复现，go 客户端调用 dubbo-java 服务端返回 415 Unsupported Media Type
'application/proto'。根因是 commit d6a6ce49f 把 tri.WithTriple() 从 HTTP/1.1
分支提升为无条件启用，导致所有 Triple 客户端默认改用 connect 编码（Content-Type: application/proto），而
dubbo-java 服务端只识别 gRPC 编码（application/grpc+proto）。
目前想到的方案是优化grpc协议下的triple-unary路径
改动量涉及一个文件：`protocol_grpc.go`，和部分注释与测试同步修改。尽管本项目旨在优化triple协议的triple-unary路径，但是grpc协议下优化同样具有收益（且高于triple协议），但这里是否需要扩大优化范围？若可以我会调整PR描述并追加commit
grpc协议的triple-unary优化效果如下：
### 128 bytes payload
| Metric | Concurrency | duplex | fastpath | Improvement |
| --- | --- | --- | --- | --- |
| QPS | 50 | 4,425.4 | 6,158.7 | +39.2% ↑ |
| QPS | 100 | 4,537.6 | 6,738.7 | +48.5% ↑ |
| P99 latency (ms) | 50 | 19.56 | 17.32 | -11.4% ↑ |
| P99 latency (ms) | 100 | 33.29 | 28.74 | -13.7% ↑ |
### 1024 bytes payload
| Metric | Concurrency | duplex | fastpath | Improvement |
| --- | --- | --- | --- | --- |
| QPS | 50 | 3,597.7 | 4,939.3 | +37.3% ↑ |
| QPS | 100 | 3,670.8 | 5,171.3 | +40.9% ↑ |
| P99 latency (ms) | 50 | 21.51 | 20.70 | -3.8% ↑ |
| P99 latency (ms) | 100 | 42.96 | 35.35 | -17.7% ↑ |
### 16384 bytes payload
| Metric | Concurrency | duplex | fastpath | Improvement |
| --- | --- | --- | --- | --- |
| QPS | 50 | 1,980.3 | 2,402.7 | +21.3% ↑ |
| QPS | 100 | 1,829.6 | 2,439.2 | +33.3% ↑ |
| P99 latency (ms) | 50 | 43.24 | 36.97 | -14.5% ↑ |
| P99 latency (ms) | 100 | 93.16 | 77.70 | -16.6% ↑ |
### 1048576 bytes (1MiB) payload
| Metric | Concurrency | duplex | fastpath | Improvement |
| --- | --- | --- | --- | --- |
| QPS | 50 | 122.9 | 133.7 | +8.8% ↑ |
| QPS | 100 | 119.4 | 101.5 | -15.0% ↓ |
| P99 latency (ms) | 50 | 1,074.68 | 1,063.45 | -1.0% ↑ |
| P99 latency (ms) | 100 | 2,400.09 | 3,148.26 | +31.2% ↓ |
## benchstat -count10
```bash
goos: linux
goarch: amd64
pkg: dubbo.apache.org/dubbo-go/v3/protocol/triple/triple_protocol
cpu: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
│ duplex10.txt │ fastpath10.txt │
│ sec/op │ sec/op vs base │
GRPCUnary/128B-12 145.1µ ± 33% 125.9µ ± 11% -13.24% (p=0.000 n=10)
GRPCUnary/1024B-12 171.7µ ± 2% 118.4µ ± 17% -31.05% (p=0.000 n=10)
GRPCUnary/16384B-12 216.8µ ± 12% 184.6µ ± 16% -14.87% (p=0.001 n=10)
GRPCUnary/1MiB-12 3.256m ± 13% 3.165m ± 13% ~ (p=0.165 n=10)
geomean 364.2µ 305.5µ -16.11%
```
| Payload | duplex (sec/op) | fastpath (sec/op) | Change | p-value |
Significance |
| --- | --- | --- | --- | --- | --- |
| 128B | 145.1µs | 125.9µs | -13.24% | 0.000 | Significant |
| 1KiB | 171.7µs | 118.4µs | -31.05% | 0.000 | Significant |
| 16KiB | 216.8µs | 184.6µs | -14.87% | 0.001 | Significant |
| 1MiB | 3.256ms | 3.165ms | -2.8% | 0.165 | Not significant |
| geomean | 364.2µs | 305.5µs | -16.11% | - | Overall positive |
也同时尝试过以下方案，但都有一定缺陷
1. 保留默认triple优化，fastpath 显式开启时才切 connect 编码 ：fastpath 默认关，WithTriple()
改成只有用户显式开 UnaryFastPath 才追加。但是默认关用户没收益；如果要有收益开启fastpath 会被强制切 connect
编码，连接dubbo-java 出现415，只能在优化收益和兼容性二选一
2. Triple 协议内支持 gRPC 编码模式：triple 客户端内部多支持一种 gRPC 编码，默认发 gRPC 保证兼容性。
但是connect 和 gRPC 是两套完全独立的实现（不同的 marshaler/unmarshaler、错误模型、header
约定）。支持grpc编码模式相当于把 grpcClientConn 全套逻辑复制进 protocol_triple.go，server 端还需要双
content-type，类似于重复造轮子，收益不高。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
