---
tags: [gRPC, performance, benchmark, compression, keepalive, optimization]
create time: 2026-05-11 17:00
---

# 性能优化与压测

## 概述

gRPC 天生就比传统 REST API 快，但要榨干它的性能上限还需要系统性的调优。从 Protobuf 序列化大小的字节级优化、连接复用策略、Compression 压缩的精确控制到 Keepalive 参数调校——再到用 Benchmark 压测验证每一个改动是否真正生效，这篇帮你建立完整的性能优化思维模型。

> [!question] gRPC 真的比 REST 快吗？
> 以典型 User Profile 消息为例（ID + Name + Email + Avatar URL）：
>
> | 格式 | Payload 大小 | 编码开销 |
> |------|-------------|---------|
> | Protobuf (binary) | ~280 bytes | Tag + varint，无字段名冗余 |
> | JSON (UTF-8) | ~950 bytes | 键名重复出现，引号包裹 |
> | JSON (minified) | ~720 bytes | 去掉空白符后的极限 |
>
> Protobuf 约为 JSON 的 **1/3 ~ 1/4**，加上 HTTP/2 的多路复用和 binary framing，通常 QPS 高 2~5 倍。但如果你已经在高效使用 HTTP/1.1 + JSON，差距可能没那么惊人。**真正的优势在于确定性与低延迟的可预测性**。

## 序列化大小优化

Protobuf 序列化体积是带宽、GC 压力和磁盘 IO 的上游因素，每次减少几十字节都可能在高并发场景下带来可感知的改善。

### int32 vs int64

Varint 编码的大小取决于数值本身，而非声明的类型。选择合适的大小能省下不少字节：

```protobuf
// 好：大部分用户 ID 不超过 int32 范围
message User {
    int32 id = 1;      // varint, 1-5 bytes
}

// 差：没必要用 int64
message UserID {
    int64 id = 1;      // varint, 1-10 bytes
}
```

规则很简单：如果数值不超过 `2^31 - 1`（约 21 亿），用 `int32` 而不是 `int64`。这能节省最多 50% 的 varint 空间。

> [!tip] uint32 vs fixed32
> 固定大小的整数（如版本号、哈希值）可以用 `fixed32` / `fixed64`，解码时省去了 varint 变长解码步骤，速度更快——但代价是每个值固定占用 4/8 字节，无论数值多小。适合对性能极其敏感且数值分布广泛的场景。

### packed repeated

```protobuf
// 默认 packed，节省空间
repeated int32 tags = 1;  // [1, 2, 3] -> 3 bytes instead of 9

// 取消 packing（几乎不需要）
repeated int32 tags = 1 [packed = false];
```

packed repeated 将连续的数值字段打包为变长整数序列，对于高频整型数组可节省 60~70% 的传输体积。

> [!important] string repeated 不能 pack
> `packed` 仅适用于数值类型和 `bytes`。`repeated string` 无法 packing，因为字符串长度不定，无法可靠分割。

### 避免不必要的嵌套

```protobuf
// 不好：多层嵌套增加 tag overhead
message Address {
    Location location = 1;
}

message Location {
    string city = 1;
    string street = 2;
}

// 好：扁平化
message Address {
    string city = 1;
    string street = 2;
}
```

每多一层嵌套就多一组 tag+size header，对小消息影响显著。

### Field Number 分配策略

连续编号不会影响 serialized size（tag+varint 对于小于 16384 的编号都是 1 byte），但跳号会浪费可读性和后续扩展的空间规划：

```protobuf
// 好：预留扩展空间
message User {
    string id    = 1;
    string name  = 2;
    string email = 3;
    // 预留 4-10 给后续新增字段
}
```

> [!seealso] 深入了解
> 更多 Field Number 的兼容细节，参见 [[hhs/gRPC/1. Protobuf 基础篇/03-字段编号与前向兼容.md]]。

### 序列化优化最佳实践速查表

| 策略 | 适用场景 | 预期收益 | 风险 |
|------|---------|---------|------|
| int32 代替 int64 | ID、状态码、计数器等 | 节省 20~50% varint 空间 | 数值溢出时需迁移 |
| packed repeated | 高频整型/字节数组标签列表 | 节省 60~70% 体积 | 需 protobuf v3 或 proto2 with `[packed=true]` |
| 扁平化消息结构 | 深层嵌套 (< 3 层) | 减少 tag overhead | 语义上是否合理 |
| 按需返回字段 | RPC 请求中指定要哪些字段 | 减少不必要的数据传输 | 需要 oneof 或 optional 支持 |
| string 替换 enum (small set) | 枚举值极少 (< 5 个) 且稳定 | 避免 tag 变化时的兼容问题 | 硬编码在二进制中 |

> [!tip] 先测量再优化
> 不要盲目猜测哪个字段最耗空间。用一个真实 payload 调用 `proto.Marshal()` 然后打印 `len()` 是最直接的诊断方式：
> ```go
> data, _ := proto.Marshal(&msg)
> fmt.Printf("Serialized: %d bytes\n", len(data))
> ```
> 逐个字段注释掉再量，就能定位"胖字段"。

## Connection Pooling

> [!warning] 最重要的一条
> **永远复用 conn，不要每次调用都 Dial。** 每次 Dial 建立新的 TCP/TLS 连接开销极大，在高并发场景下会导致端口耗尽和性能断崖式下跌。

### conn 管理原则

gRPC 内部已经实现了连接池（transport layer multiplexing），底层自动维护多路复用的 HTTP/2 连接。你只需要记住三个原则：

1. **一目标一连接**：同一个 target address 全局共享一个 `*grpc.ClientConn`
2. **进程生命周期内复用**：conn 应在应用启动时创建，退出的时候关闭
3. **并发安全**：`*grpc.ClientConn` 天生支持多 goroutine 同时使用

```go
var conn *grpc.ClientConn

func initClient(addr string) error {
    var err error
    conn, err = grpc.DialContext(context.Background(), addr,
        grpc.WithTransportCredentials(credentials.NewTLS(nil)),
        grpc.WithKeepaliveParams(keepalive.ClientParameters{
            Time:              10 * time.Second,
            Timeout:           5 * time.Second,
            PermitWithoutStream: true,
        }),
    )
    return err
}

// defer func() { conn.Close() }() // 退出时统一关闭
```

> [!note] 为什么不用 WithConnectTimeout？
> gRPC Go SDK 没有 `grpc.WithConnectTimeout` 这个选项。连接超时应通过 `context.WithTimeout` 配合 `grpc.DialContext` 控制；或者使用自定义 dialer 包装 `net.Dialer.Timeout`。

### 连接数与并发调优

#### MaxConcurrentStreams

```go
server := grpc.NewServer(
    grpc.MaxConcurrentStreams(100), // default: 100
)
```

MaxConcurrentStreams 决定了单个 HTTP/2 连接上允许的最大并行流数量。调整依据：

| 场景 | 推荐值 | 说明 |
|------|--------|------|
| 高频短流（Unary） | 100（默认） | 默认值即可，新 Stream 立即关闭 |
| 低频长流（BiDi Streaming） | 10-50 | 降低以减少内存占用 |
| 超大流量（万级 QPS） | 500-1000 | 配合后端 capacity 调整 |

> [!danger] 不要设得太高
> 过大的 MaxConcurrentStreams 意味着每个连接上可能堆积大量未完成的 Stream，消耗服务器内存。生产环境建议设置为实际峰值需求的 1.5~2 倍。

## Compression（Gzip 压缩）

Per-call 级别的压缩控制：

```go
// Client 侧调用时指定压缩算法
resp, err := client.GetUser(ctx, req, grpc.UseCompressor(gzip.Name))
```

何时启用 gzip 压缩的判断条件：

| 条件 | 建议 |
|------|------|
| payload > 1KB | 启用，收益明显 |
| payload < 100B | 禁用，header 开销超过压缩收益 |
| CPU 受限的服务 | 谨慎启用，解压有 CPU cost |
| 延迟敏感型 API | 不加压缩，网络带宽通常不是瓶颈 |

> [!tip] Server-side 全局压缩
> gRPC 官方不支持 server-side 的全局压缩 interceptor（这是一个已知的 limitation）。如果需要全局压缩，有两种替代方案：
>
> 1. **在拦截器中对 Response 做 gzip 压缩后写入**——但需要客户端同步解压
> 2. **在 lbloadbalancer 或 ingress 层统一处理**——由 Nginx/envoy 承担压缩工作
>
> 多数情况下，推荐在 **Client 侧按接口特性选择性开启**，这样更精细可控。

```mermaid
flowchart TD
    Start["是否需要压缩?"] --> Payload{"Payload > 1KB?"}
    Payload -->|"否"| Disable["禁用压缩\n节省 CPU"]
    Payload -->|"是"| CPU{"服务 CPU 充足?"}
    CPU -->|"否"| Disable
    CPU -->|"是"| Network{"带宽紧张?"}
    Network -->|"否"| Decision["视延迟敏感度而定\n通常仍然值得压缩"]
    Network -->|"是"| Enable["启用压缩\ngzip/zstd"]
    Enable --> Zstd{"是否可用 zstd?"}
    Zstd -->|"是"| Best["首选 zstd\n压缩率更高, 速度更快"]
    Zstd -->|"否"| Gzip["使用 gzip\n兼容最广"]

    style Best fill:#00D866,color:#fff
    style Gzip fill:#4FC08D,color:#fff
    style Disable fill:#FF6B6B,color:#fff
```

> [!question] gzip 和 zstd 怎么选？
> **zstd 是目前的最佳选择**：压缩率与 gzip 相当或更好，解压缩速度快 30%+。gRPC 自 v1.35 起原生支持 zstd compressor：
> ```go
> import "google.golang.org/grpc/encoding/zstd"
> // zstd 自动注册为 "zstd"，直接在 call option 中使用
> client.GetUser(ctx, req, grpc.UseCompressor(zstd.Name))
> ```

## Keepalive 调优

连接保活是确保链路健康的关键，错误的 keepalive 参数是导致"偶发超时""连接静默断裂"等问题的常见原因。

### Client Parameters

```go
cap := keepalive.ClientParameters{
    Time:                10 * time.Second, // 发送 ping 间隔
    Timeout:             5 * time.Second,  // 等待 pong 超时
    PermitWithoutStream: true,             // 空闲时也发送 ping
}
grpc.WithKeepaliveParams(cap)
```

| 参数 | 默认值 | 含义 | 推荐调整 |
|------|-------|------|---------|
| `Time` | 2h | 两次 ping 之间的间隔 | 内网 10~30s，跨云 30~60s |
| `Timeout` | 20s | 服务端无响应则断开 | 通常保持默认 |
| `PermitWithoutStream` | false | 即使无活动流也发送 ping | **强烈建议设为 true** |

> [!tip] 为什么要设 PermitWithoutStream？
> 默认值为 false 意味着：如果一个 Stream 完成后不再新建流，客户端将不再发送 ping。此时中间件（Nginx、Cloud LB、防火墙）可能认为连接已闲置而提前断开——等你下次发消息时才会发现连接断了，导致 `unavailable` 错误。设为 true 后可让 gRPC 自行维护连接健康状态。

### Server Parameters

```go
scp := keepalive.ServerParameters{
    Time:    10 * time.Second,
    Timeout: 5 * time.Second,
}
grpc.KeepaliveParams(scp)
```

| 参数 | 默认值 | 含义 | 推荐调整 |
|------|-------|------|---------|
| `Time` | 2h | 两次 ping 间隔 | 同上 |
| `Timeout` | 20s | 客户端无响应则断开 | 通常保持默认 |
| `MinTime` | 5m | 客户端最小 ping 频率 | 防止客户端频繁 ping |

> [!info] MinTime 保护服务端
> 如果客户端 keepalive Time 设置过小（比如 1s），服务端会通过 `MinTime` 拒绝太快收到 ping 的连接。这是防止恶意或配置错误的客户端造成服务端资源浪费的安全机制。

## Benchmark 方法学

标准 gRPC benchmark 模板：

```go
func BenchmarkGRPCUnaryCall(b *testing.B) {
    lis, _ := net.Listen("tcp", "localhost:0")
    s := grpc.NewServer()
    pb.RegisterUserServiceServer(s, mockServer{})
    go s.Serve(lis)
    defer s.Stop()

    conn, _ := grpc.Dial(lis.Addr(),
        grpc.WithTransportCredentials(insecure.NewCredentials()),
        grpc.WithDefaultCallOptions(grpc.UseCompressor(gzip.Name)),
    )
    defer conn.Close()

    client := pb.NewUserServiceClient(conn)

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _, _ = client.GetUser(context.Background(), &pb.GetUserRequest{Id: "1"})
    }
    b.StopTimer()
}
```

运行：`go test -bench=. -benchmem -benchtime=5s`

关键 flag 说明：

- `-benchmem`: 打印内存分配统计
- `-benchtime=5s`: 至少跑 5 秒以确保数据稳定
- `-cpuprofile=cpu.pprof`: 导出 CPU profile 进一步分析

### 解读 Benchmark 结果

```
pkg: myapp/pb
BenchmarkGRPCUnaryCall-8        35421            33829 ns/op         4128 B/op      42 allocs/op
```

| 指标 | 含义 | 优化方向 |
|------|------|---------|
| `ns/op` | 单次请求平均耗时 | 降低 P99、优化串行逻辑 |
| `B/op` | 单次请求堆分配字节数 | 减少临时对象、复用 buffer |
| `allocs/op` | 单次请求 heap 分配次数 | 结合 `sync.Pool` 复用对象 |

### 不同模式的基准对比

| 模式 | 压缩 | Payload | 典型 QPS (单核) | 典型 Latency |
|------|------|--------|----------------|-------------|
| Unary | 无 | 500B | 18K-25K | 40-55 μs |
| Unary | gzip | 500B | 12K-18K | 55-80 μs |
| Unary | gzip | 5KB | 10K-15K | 80-150 μs |
| Unary | gzip | 50KB | 3K-6K | 200-500 μs |
| Server Stream | 无 | 每 chunk 1KB | 5K-8K | 120-200 μs |
| BiDi Stream | gzip | 每 chunk 2KB | 2K-4K | 300-600 μs |

> [!note] 注意事项
> 1. 服务端和客户端在同一个 benchmark 函数中启动和关闭——但这不代表你应该在生产环境中这样做。
> 2. 使用 `b.ResetTimer()` 排除 setup 耗时。
> 3. 忽略返回值 (`_ =`) 以测量 pure throughput，保留返回值以测量 real-world latency。
> 4. 以上数据仅作参考基准，实际性能取决于硬件、网络、Protobuf 消息结构和 handler 复杂度。

## 压测实战

### 端到端压测架构

```mermaid
flowchart LR
    subloader["🧪 压测客户端"]
    subclient["负载均衡"]
    subservice["gRPC Service (N 副本)"]
    subdb[("Database")]

    subloader -->|"HTTP/gRPC"| subclient
    subclient -->|"round-robin"| subservice
    subservice -->|"query"| subdb

    style subloader fill:#E1BEE7
    style subclient fill:#BBDEFB
    style subservice fill:#C8E6C9
    style subdb fill:#FFCCBC
```

一个简单的端到端压测流程：

```
1. 准备 mock 数据 → 构造真实的 Proto Message
2. 部署 1-N 个 service pod
3. 用 hey/k6/wrk 发起压力测试
4. 记录 P50/P90/P99/Latency/SLO 达标率
5. 逐步增加并发直到 hitting bottleneck
```

### 常用工具推荐

| 工具 | 协议支持 | 特点 | 适用场景 |
|------|---------|------|---------|
| [hey](https://github.com/rakyll/hey) | HTTP/1.1, h2c | 简单快速，Go 编写 | 快速 sanity check |
| k6 | gRPC via JS API | 脚本灵活，带可视化 | 完整 E2E 压测 |
| ghz | gRPC native | 专为 gRPC 设计，YAML 配置 | Protocol-level benchmark |
| custom Go bench | gRPC native | 完全可控 | 开发阶段集成测试 |

```bash
# ghz 示例：一键压测已有 proto
ghz --call demo.UserService.GetUser \
    --data '{"id": "test-001"}' \
    -n 10000 -c 100 \
    localhost:50051
```

## 性能调优 Checklist

| 优化项 | 预估提升 | 难度 | 优先级 |
|--------|---------|------|--------|
| 复用连接（不重新 Dial） | 50%+ | ⭐ | 🔴 Critical |
| 减少 proto 文件大小 | 20-60% | ⭐⭐ | 🔴 Critical |
| 批量 RPC（而非 N 次 unary） | 80%+ | ⭐⭐ | 🔴 Critical |
| Keepalive 调优 | 减少断连 | ⭐⭐ | 🟡 High |
| 开启 gzip（大 payload） | 30-80% | ⭐ | 🟡 Medium |
| MaxConcurrentStreams 调优 | 少量 | ⭐ | 🟢 Low (specialized) |
| Buffer pool 复用 (`sync.Pool`) | 5-15% | ⭐⭐⭐ | 🟢 Edge case |

> [!tip] 优化顺序建议
> 先做前两项（连接复用 + proto 瘦身），它们几乎零成本且回报最高。其余优化务必先用 benchmark 验证——"感觉变快了"不等于"数据上变快了"。

## 监控关键指标

使用 OpenTelemetry gRPC interceptor 自动采集指标：

```go
import _ "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"

// otelgrpc 自动产出的核心指标：
// rpc.server.duration.p50 / p99    — 服务端延迟分位
// rpc.client.sent.total_requests   — 客户端发出请求总量
// rpc.server.received_messages_per_rpc  — 每次 RPC 接收消息数均值
// grpc.transport.network.sent.bytes / received.bytes — 网络流量
```

这些指标接入 Prometheus 后，可以监控：

- P99 延迟是否高于预期
- 每秒请求量的突增/突降
- 网络发送/接收字节的异常波动
- 未解决的 stream 堆积数

```yaml
# prometheus scrape_config 示例
scrape_configs:
  - job_name: 'grpc-services'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['service-a:8080', 'service-b:8080']
    # otelgrpc 默认暴露 /metrics 路径
```

> [!note] 进阶链路追踪
> 除了延迟和吞吐量，还需要关注调用链上下文。详见 [[hhs/gRPC/5. 中间件与拦截器/16-日志与链路追踪.md]]。

## 典型问题诊断流程

```mermaid
flowchart TD
    A["慢或超时"] --> B{"P99 > P50 * 10?"}
    B -->|Yes| C["网络问题\n查 keepalive 和 DNS resolution"]
    B -->|No| D["服务端处理慢\nProfile, DB query, serialization"]

    C --> E{"K8s 或 LB 层?"}
    E -->|Yes| F["调整 keepalive params\n放宽中间件 idle timeout"]
    E -->|No| G["tcpdump + h2spec 抓包分析"]

    D --> H["go test -bench\n定位瓶颈"]

    style D fill:#FFD43B
    style F fill:#00D866,color:#fff
    style H fill:#4FC08D,color:#fff
```

## 关联笔记

- [[hhs/gRPC/1. Protobuf 基础篇/01-Protobuf 语法与消息定义.md]]
- [[hhs/gRPC/1. Protobuf 基础篇/02-数据类型详解.md]]
- [[hhs/gRPC/1. Protobuf 基础篇/03-字段编号与前向兼容.md]]
- [[hhs/gRPC/4. 客户端开发/11-Client 连接与 Dial.md]]
- [[hhs/gRPC/5. 中间件与拦截器/16-日志与链路追踪.md]]