MCP 系统的性能与扩展性，决定了其在生产环境中的可用性。从连接建立到 Tool 调用，从 Token 消耗到 Server 扩容，每个环节都有值得优化的空间。

---

一句话解释

MCP 性能优化是在协议层、传输层、应用层三个维度同时发力，使系统在高并发、大数据量场景下依然保持低延迟和高吞吐。

---

1. 基本定义

MCP 性能关注以下核心指标：

指标	说明	典型目标
初始化延迟	Client 连接 Server 到可用状态的时间	< 500ms
Tool 调用延迟	发送请求到获得结果的端到端时间	< 2s（简单调用）
吞吐量	单位时间内处理的 Tool 调用数	> 100 req/s
Token 成本	每次交互消耗的 Token 量	随业务可控

---

2. 初始化延迟

Server 启动时间直接影响用户体验。

来源：

• Server 进程冷启动（进程创建、依赖加载）
• 网络连接建立（尤其是 SSE 长连接）
• 能力握手（initialize → initialized 往返）
• 外部资源预热（数据库连接、API 鉴权）

优化手段：

• Server 进程池预启动，避免冷启动
• 能力列表懒加载，握手阶段只返回摘要
• 连接预热：Client 在后台提前建立连接

---

3. 能力列表规模

当 Server 暴露数百个 Tool 时，tools/list 返回的 JSON 可能超过 50KB，直接推给 LLM 会消耗大量 Token 并增加推理延迟。

问题本质： 模型上下文窗口有限，Tool 描述越多，每次请求的 input Token 消耗越高，模型选择 Tool 的准确率也下降。

应对策略：

• 能力裁剪：根据当前任务只注入相关 Tool（见第 21 节）
• 分页加载：tools/list 支持 cursor 分页，避免一次性全量返回
• 分组注册：将 Tool 按领域分组，按需激活

---

4. Tool 调用延迟

Tool 调用延迟 = 网络传输 + Server 处理 + 外部依赖响应。

常见瓶颈：

Client → JSON-RPC 序列化 → 网络传输 → Server 反序列化 → 业务逻辑 → 外部 API → 返回
         ~1ms              ~5ms       ~2ms              ~10ms        ~50-500ms

优化：

• 减少不必要的参数校验层级
• 对外部 API 调用设置合理超时
• 使用连接池复用数据库 / HTTP 连接

---

5. 连接复用

每次新建连接的开销不可忽视。

策略：

• 单 Client 对单 Server 复用同一 transport 实例
• 使用 HTTP Keep-Alive 或 SSE 长连接
• 连接池管理多个 Server 的连接

Client ───复用──→ Transport ───长连接──→ Server

---

6. 并发处理

MCP Server 应支持并发请求处理。

关键设计：

• 每个 JSON-RPC 请求独立处理，无共享状态阻塞
• 使用异步 I/O（asyncio / goroutine / Node.js event loop）
• 对有状态操作（写入）加锁，对无状态操作（查询）并行放行

注意： MCP 协议本身是无状态的请求-响应模式，天然支持并发；但 Server 内部若有全局状态（如文件写入），需自行处理竞争条件。

---

7. 背压（Backpressure）

当 Client 发送请求的速度超过 Server 处理能力时，需要背压机制。

实现方式：

• Server 端：请求队列设置上限，超出时返回 -32000 错误或主动延迟响应
• 传输层：TCP 窗口自动调节；HTTP/2 流控
• Client 端：限制并发请求数（semaphore / 令牌桶）

---

8. 批量调用

对于需要多次调用 Tool 的场景，逐次往返效率低下。

方案：

• JSON-RPC Batch：将多个请求放入一个数组，一次发送
• Client 端合并：将同一轮对话中的多个独立 Tool 调用合并
• Server 端批处理接口：为高频场景提供 tools/batch_call 扩展

注意： 批量调用的结果顺序需与请求顺序对应，或使用 id 字段匹配。

---

9. 缓存策略

能力缓存

tools/list 结果在 Server 能力不变时可以缓存，避免每次握手都重新拉取。Client 可通过 capabilities 指纹判断是否需要刷新。

结果缓存

对幂等 Tool 调用（如查询类），Client 可缓存结果，设置 TTL：

cache_key = hash(server_id, tool_name, sorted_params)
ttl = 60s  # 根据业务场景调整

---

10. 分页

resources/list、tools/list 等接口在数据量大时必须支持分页。

协议约定：

• 响应中包含 nextCursor 字段
• Client 按需请求下一页
• 避免一次性返回数千条记录

---

11. 大 Resource 处理

当 Resource 内容超过 1MB 时，直接内联返回会导致内存压力和传输延迟。

策略：

• resources/read 返回引用（URI），Client 按需拉取内容片段
• 支持 Range 请求，分段读取大文件
• 对超大内容提供 resources/subscribe 流式订阅

---

12. 流式返回

长耗时 Tool 调用应支持流式返回（Streaming）。

实现：

• 使用 SSE（Server-Sent Events）传输中间结果
• 或采用 JSON-RPC Notification 逐步推送进度

Server → notification: { progress: 20%, message: "正在查询..." }
Server → notification: { progress: 80%, message: "整理结果..." }
Server → response: { result: {...} }

---

13. 超时管理

合理的超时设置是稳定性的基础。

场景	建议超时
初始化握手	5s
普通 Tool 调用	30s
长任务（文件处理）	5min，配合流式进度
连接空闲	60s 发心跳

Client 和 Server 都应实现超时，避免一端挂起导致资源泄漏。

---

14. Server 水平扩展

单 Server 实例无法满足高并发时，需要水平扩展。

前提： Server 必须是无状态的（或状态外置，见第 15 节）。

架构：

Client → Load Balancer → Server Pool [S1, S2, S3]
                            ↓
                        Redis / DB（共享状态）

注意：

• 同一会话的请求应路由到同一实例（粘性会话），或完全无状态化
• 能力注册需支持服务发现（Consul / Nacos / K8s Service）

---

15. 状态外置

将会话状态、调用上下文存入外部存储（Redis、数据库），使 Server 实例可随时替换。

存储内容：

• 会话 ID → 当前激活的 Tool 列表
• 调用历史（用于审计和重试）
• 中间结果（长任务断点续传）

---

16. 限流

防止单个 Client 过度消耗 Server 资源。

常用算法：

• 令牌桶（Token Bucket）：允许一定程度的突发流量
• 滑动窗口（Sliding Window）：更平滑的速率控制
• 并发连接数限制：单 Client 最多 N 个并发请求

限流触发时返回 JSON-RPC error code -32029（Rate Limited），Client 应实现指数退避重试。

---

17. 熔断

当 Server 连续失败时，Client 应主动熔断，避免雪崩。

状态机：

参数建议：

• 失败阈值：5 次连续失败
• 熔断时长：30s
• 试探请求数：1

---

18. 队列（异步处理长任务）

对于耗时超过 30s 的任务，应转为异步队列处理。

流程：

1. Client 调用 Tool，Server 立即返回 task_id
2. Server 将任务放入消息队列（Redis Stream / RabbitMQ）
3. Worker 消费任务，处理完成后写入结果存储
4. Client 通过 notifications/progress 或轮询获取结果

---

19. 成本控制（Token 消耗监控）

每次 Tool 调用都会转化为 LLM 的 input/output Token。

监控维度：

• 每次调用的 Tool 描述 Token 数
• 结果返回的 Token 数
• 累计 Token 消耗趋势

控制手段：

• 精简 Tool 描述（减少 input Token）
• 压缩返回结果（减少 output Token）
• 设置每日 Token 预算上限

---

20. 多 Server 路由优化

当 Client 连接多个 Server 时，需要根据任务智能路由。

策略：

• 静态路由：根据 Tool 名称前缀分发（如 github_* → GitHub Server）
• 动态路由：根据 Server 负载和延迟选择最优实例
• 语义路由：根据用户意图匹配最相关的 Server（需 Embedding 索引）

---

21. 能力裁剪

不是所有 Tool 都需要发给模型。

裁剪策略：

全量 Tool 列表（200个）
    ↓ 根据当前任务上下文过滤
相关 Tool 子集（15-30个）
    ↓ 发送给 LLM
模型只看到精简的能力描述

裁剪依据：

• 用户当前对话意图
• Tool 的历史调用频率
• Tool 所属的领域分组

---

22. 上下文膨胀控制

随着对话轮次增加，累积的 Tool 调用结果会撑爆上下文窗口。

对策：

• 对历史 Tool 结果做摘要压缩
• 超过 N 轮的调用结果只保留摘要
• 使用 sliding window 只保留最近 K 轮完整上下文

---

性能优化分层架构

---

设计原则

1. 默认无状态：Server 不保存会话状态，状态外置到 Redis / DB
2. 渐进式加载：能力列表、Resource 内容按需加载，不一开始就全量推送
3. 快速失败：超时时立即报错，不默默等待
4. 可观测：每次调用的延迟、Token 消耗都可追踪（参见 MCP日志与可观测性）
5. 弹性优先：限流 + 熔断 + 队列，保护系统在高负载下不崩溃

---

常见误区

误区	正确做法
把所有 Tool 都发给模型	按任务裁剪，只发送相关子集
Server 保存会话状态	状态外置，Server 无状态化
超时设得越长越好	根据场景分层设置，长任务用异步
同步等待所有结果	支持流式返回和异步队列
忽略 Token 成本	建立监控，设置预算上限
单 Server 扛所有流量	水平扩展 + 负载均衡

---

检查清单

• tools/list 返回结果是否分页？
• Tool 调用是否设置了合理超时？
• Server 是否无状态，支持水平扩展？
• 是否有连接复用机制？
• 是否实现了限流和熔断？
• 长任务是否走异步队列？
• Tool 描述 Token 数是否纳入监控？
• 是否有能力裁剪策略？
• 大 Resource 是否支持分段读取？
• 是否实现了上下文膨胀控制？

---

关联笔记

• MCP Server设计 — Server 端的架构决策直接影响性能
• MCP Client设计 — Client 的缓存、并发、重试策略
• MCP日志与可观测性 — 性能监控的基础设施
• MCP调试与诊断 — 定位性能瓶颈的方法论
• MCP测试策略 — 性能测试与压测方案
• MCP协议基础 — 协议层的传输机制