性能调优指南
概述
负载均衡作为流量的总入口，其性能直接影响所有后端服务的响应速度。矩尺平台提供了多层面的性能调优选项，从客户端连接、SSL 握手、HTTP 传输到后端转发，每个环节都有可优化的参数。
本文档按照请求的流转路径组织，帮助您按链路逐段优化。
一、客户端侧优化
TCP Fast Open（TFO）
作用： 让客户端在 TCP 三次握手的 SYN 包中携带数据，减少一次 RTT 的等待时间。
配置位置： 虚拟服务配置 → 开启"TCP Fast Open"
适用场景： 移动端 APP、长距离网络访问。可减少首次连接约 1 个 RTT（通常 10-50ms）。注意：部分老旧操作系统和网络设备不支持 TFO，单向开启没有意义。
HTTP/2
作用： 多路复用、头部压缩、服务器推送，在单个 TCP 连接上并发处理多个请求，减少连接建立开销。
配置位置： HTTPS 虚拟服务配置 → 开启"启用 HTTP/2"
适用场景： 大量小文件请求的前端应用（如 SPA 页面加载大量 JS/CSS）。对于大文件下载或少量大请求的 API 场景，收益不明显。
KeepAlive 长连接
作用： 允许客户端与负载均衡之间复用同一个 TCP 连接发送多个 HTTP 请求，避免每个请求都重新建立 TCP 连接（三次握手 + SSL 握手）。这是对客户端响应速度影响最大的优化之一——相当于 NGINX 的 keepalive 系列指令。
配置位置： 虚拟服务配置 → 客户端长连接相关参数
关键参数：
| 参数 | 含义 | 建议值 |
|---|---|---|
| 使用长连接 | 总开关，开启后客户端可使用 HTTP Keep-Alive | 开启 |
| 最长空闲时间 | 连接上无任何请求后等待的最长时间，超时后关闭连接 | 60-120 秒。API 短连接场景降低到 15-30 秒 |
| 最长维持时间 | 单个 KeepAlive 连接允许存活的总时长，无论是否有请求 | 建议不低于最长空闲时间。设为 0 表示不限制总时长 |
| 最大传输 HTTP 请求数 | 单个 KeepAlive 连接上最多允许传输多少个 HTTP 请求，达到后关闭连接 | 100-1000。设为 0 表示不限制数量 |
| KeepAlive 探测最大间隔 | 探测连接是否存活的间隔，仅在某些网络环境下生效 | 默认即可 |
三个参数的关系：
一个 KeepAlive 连接的生命周期受三条规则约束，
任何一条触发即关闭连接：
1. 空闲时间 > 最长空闲时间 → 关闭
2. 存活总时长 > 最长维持时间 → 关闭
3. 已处理请求数 > 最大传输请求数 → 关闭调优思路：
- API 网关场景（客户端频繁短请求）：开启长连接，空闲时间设 15-30s，请求数设 100-500
- 浏览器访问场景（页面加载后长时间空闲）：空闲时间设 60-120s，请求数可适当放宽
- WebSocket 场景：最长维持时间需覆盖 WS 会话时长，空闲时间设为 0（不因空闲而断开）
HTTP/2 多路复用
作用： 在单个 TCP 连接上并发处理多个 HTTP 请求（多路复用），配合头部压缩（HPACK）显著减少连接数和传输量。
配置位置： HTTPS 虚拟服务配置 → 开启"启用 HTTP/2"
| 参数 | 含义 | 建议值 |
|---|---|---|
| 启用 HTTP/2 | 总开关 | HTTPS 服务建议开启 |
| 最大并发流数 | 单个 HTTP/2 连接上最多并发多少个请求流 | 默认 128，按需调整 |
适用场景： 大量小文件请求的前端应用（SPA 加载大量 JS/CSS）。对于大文件下载或少量大请求的 API 场景，收益不明显。
注意：主流浏览器仅支持 HTTPS 下的 HTTP/2（需要 ALPN 协商），HTTP 协议的虚拟服务无法使用 HTTP/2。
并发连接限制
作用： 限制单个客户端 IP 到虚拟服务的最大并发连接数，防止单个客户端耗尽连接资源。
配置位置： 七层访问策略 → 并发连接限制
建议值： 按业务类型设置。普通 Web 网站 50-100，API 网关可更高。超过限制的请求将被拒绝。
二、SSL/TLS 优化
SSL 握手是高开销操作——每次完整的 TLS 握手需要 2 个 RTT 和多次非对称加密计算。矩尺提供两种会话复用机制减少握手次数。
Session 缓存
作用： 负载均衡在内存中缓存 SSL 会话 ID。同一个客户端短时间内重连时，跳过完整握手，直接复用上次协商的密钥。可减少约 50%-80% 的握手耗时。
配置位置： SSL 客户端策略 → 开启"Session 缓存"
适用场景： 单机转发引擎部署、客户端短时间内频繁重连。
注意： 缓存存储在单台引擎的内存中，主备或 ECMP 模式下不同引擎之间不共享缓存。
Session Ticket
作用： 由负载均衡生成加密 ticket 发给客户端保存。客户端下次连接时带上 ticket，服务端解密后直接恢复会话。ticket 存储在客户端侧，多台引擎之间无需共享内存。
配置位置： SSL 客户端策略 → 开启"Session Ticket"
适用场景： 集群部署（主备/ECMP），客户端可能被分配到不同引擎。建议与 Session 缓存同时开启，互为补充。
Session 过期时间
作用： 会话复用的有效时长。时间越长，复用率越高，但被重放攻击的风险越大。
建议值： 300-1800 秒（5-30 分钟）。对于大多数 Web 应用，10 分钟是合理的平衡点。
SSL 数据缓冲区大小
作用： 发送 SSL 数据帧时的缓冲区大小。过小导致数据分片过多，过大增加内存占用。
建议值： 默认 16KB 适合大多数场景。大文件下载场景可增大到 32KB。
支持的 SSL 协议
建议： 仅勾选 TLS 1.2 和 TLS 1.3，关闭 TLS 1.0/1.1。TLS 1.3 将握手从 2-RTT 减少到 1-RTT，性能更好。
三、后端转发优化
TCP 连接复用
作用： 将众多客户端请求复用到与后端服务器建立的少量 TCP 连接上，减少后端服务器的并发连接数和建连开销。这是最常见的性能优化手段——相当于 NGINX 的 keepalive 指令。
配置位置： 七层 HTTP 策略 → 开启"TCP 连接复用"
工作原理：
未开启：客户端 A → 新建连接 → 后端服务器
客户端 B → 新建连接 → 后端服务器
（1000 个客户端 = 1000 个后端连接）
开启后：客户端 A → ┐
客户端 B → 复用连接池（如 32 个连接）→ 后端服务器
客户端 C → ┘
（1000 个客户端共享 32 个后端连接）建议： 对大多数 Web 应用开启。如果后端服务对连接数有严格限制（如每个连接关联特定状态），谨慎使用。
HTTP 压缩
作用： 对文本类响应内容进行 Gzip 或 Brotli 压缩后传输，减少网络带宽消耗和传输时间。通常可将 JSON/HTML/CSS/JS 压缩到原始大小的 20%-30%。
配置位置： 七层 HTTP 策略 → HTTP 压缩策略
建议压缩类型：
text/htmltext/csstext/plainapplication/jsonapplication/javascriptapplication/xml- 避免压缩已压缩的格式：图片（
image/*）、视频、.zip、.gz等
Brotli vs Gzip： Brotli 压缩率比 Gzip 高约 15-25%，但压缩速度稍慢。对于静态资源建议用 Brotli 预压缩（见下文），动态响应用 Gzip 以保持低延迟。
预压缩（静态资源专用）
作用： 提前将静态文件压缩好（.gz / .br），负载均衡直接传输压缩文件，完全省去实时压缩的 CPU 开销。这是静态资源场景下最有效的性能优化。
配置位置： 静态资源配置 → 开启"启用预压缩" → 选择 Gzip 或 Brotli
与实时压缩的区别：
| 对比 | 实时压缩（七层策略） | 预压缩（静态资源） |
|---|---|---|
| CPU 开销 | 每个请求实时压缩 | 零（提前压好直接传） |
| 压缩率 | 取决于压缩级别 | 可在构建时用最高压缩级别 |
| 适用 | 动态 API 响应 | 静态文件（JS/CSS/HTML） |
详细配置参见 静态资源托管服务配置。
HTTP 请求/响应缓冲
作用： 控制负载均衡是否缓存完整的请求/响应包体后再转发。
配置位置： 虚拟服务配置 → 缓存请求 / 缓存响应包体
- 开启缓冲： 收到完整包体后再转发给后端，确保后端不会因前端网络慢而阻塞。适合常规场景，但会占用转发引擎本地磁盘并产生磁盘IO。
- 关闭缓冲（默认）： 收到数据即转发（流式传输），减少首字节延迟。适合大文件上传/下载、实时流媒体、Server-Sent Events 等。
被动健康检查失败重试
作用： 当后端服务器返回错误或连接失败时，自动换一台健康节点重试请求。注意：仅对非幂等请求（POST）需谨慎开启，避免重复操作。
配置位置： 虚拟服务配置 → 开启"被动健康检查失败换服务器重发"
四、服务器池侧优化
负载均衡算法选择
算法的选择直接影响后端节点的负载分布均匀度：
| 算法 | 性能特征 | 推荐场景 |
|---|---|---|
| 轮询（加权） | 简单、低开销 | 后端服务器性能相当 |
| 最小连接数（加权） | 动态适应，稍高开销 | 后端性能不均、长连接场景 |
| 最快响应 | 实时调整，开销最高 | 对延迟敏感，后端性能差异大 |
| 一致性哈希 | 节点变化时仅局部重分配 | 缓存服务器集群 |
并发连接限制（服务器池侧）
作用： 限制单个后端服务器节点的最大并发连接数，防止某台节点被压垮。
配置位置： 服务器池 → 节点配置 → 并发连接限制
建议值： 根据后端服务器的实际承载能力设置。通过监控分析页面观测节点实际连接数，设置约为峰值的 120%。
温暖上线
作用： 节点上线后流量逐步增加，避免冷启动的新节点被瞬时大量请求打垮。详见 产品技术架构 - 温暖上线。
配置： 恢复时间（上线后等待期，0-600s）+ 温暖时间（流量缓慢增长期，0-600s）
五、日志与监控开销控制
日志上报阈值
作用： 限制每秒最大上报日志条数，超出部分丢弃。防止高频日志 I/O 拖慢转发引擎。
配置位置： 分发规则 → 每秒上报日志数
建议： 核心业务接口设置较高阈值（如 1000/s），高频接口设置较低阈值（如 100/s）。注意此值不是越大越好——每条日志都会消耗 I/O。
记录全部 HTTP 头部
作用： 记录完整的请求和响应头部，对排查协议问题非常有用，但会显著增加日志数据量。
建议： 不要在全部规则上全量开启。 仅在排查特定问题（如 Header 丢失、CORS 异常）时临时开启，排查完毕后关闭。
日志中心 vs Syslog 外发
Syslog 外发将日志推送到外部平台（ELK/Splunk），不占用管理节点存储。高流量场景建议使用 Syslog 方式，避免管理节点磁盘压力。
六、网络层优化
MTU 配置
作用： 最大传输单元。过大导致分片，过小增加包头开销。默认 1500 适合以太网。如果使用 VXLAN、GRE 等隧道协议，需适当减小（如 1400-1450）为隧道头部留空间。
配置位置： 网络接口 → 配置 MTU
网口聚合
作用： 多个物理接口捆绑为一个逻辑接口，增加带宽并提供链路冗余。这是网络层最直接的性能提升手段。
详细配置参见 网络地址与路由管理。
调优速查表
| 优化目标 | 配置项 | 位置 | 建议值 |
|---|---|---|---|
| 减少握手延迟 | TCP Fast Open | 虚拟服务 | 开启 |
| 减少连接数 | HTTP/2 | 虚拟服务 | 开启（HTTPS） |
| 减少 SSL 握手 | Session 缓存 + Ticket | SSL 策略 | 同时开启 |
| 减少后端连接数 | TCP 连接复用 | 七层策略 | 开启 |
| 减少传输量 | HTTP 压缩（Gzip） | 七层策略 | 开启 |
| 静态资源零 CPU | 预压缩（Brotli） | 静态资源 | 开启 |
| 避免打垮新节点 | 温暖上线 | 服务器池 | 恢复 10s / 温暖 60s |
| 防日志拖慢 | 日志上报阈值 | 分发规则 | 按 QPS 合理设置 |
| 带宽扩容 | 网口聚合 | 网络接口 | LACP 聚合 |
各配置项的详细操作参见对应的用户手册和配置指南。性能指标的实时监控参见 监控分析。