MCP Server 高并发下响应延迟超过 200ms 通常源于工具函数执行阻塞或传输层开销过大。建议优先排查工具函数的 I/O 等待时间，并确认传输协议（SSE 或 STDIO）是否匹配当前并发场景，注意异步改造可能带来状态管理复杂度。
先说结论：优化核心在于减少单个请求的工具执行耗时和调整服务器并发模型，而非单纯增加硬件资源。
- 先定位：区分延迟是来自网络传输、JSON 序列化还是具体的 Tool 业务逻辑。
- 先做：将阻塞式 I/O 改为异步非阻塞实现，并引入结果缓存机制。
- 再验证：通过压测对比优化前后的 P99 延迟数据，确认无回归错误。
命令速用版
MCP Server 多为自定义代码实现，无统一命令，但可使用以下通用 profiling 思路快速定位：
- Node.js 环境：使用
node `--inspect`配合 Chrome DevTools 查看 Event Loop 延迟。 - Python 环境：使用
py-spy record -o profile.svg -- python server.py生成火焰图。 - 网络层：使用
curl -w "@format.txt" -o /dev/null -s http://localhost:port测量握手与传输耗时。
为什么会这样
延迟过高主要是因为 MCP 协议基于 JSON-RPC 2.0，频繁序列化开销叠加工具链的同步阻塞调用。
MCP Server 在接收到 Client 的 tools/call 请求后，需要执行具体的业务逻辑（如查询数据库、调用外部 API）。如果这些逻辑是同步阻塞的，高并发下请求会排队等待。此外，若使用 STDIO 传输模式，进程间通信带宽受限，也会在高吞吐时增加延迟。公开资料中没有看到可靠的量化数据表明特定配置能固定降低多少毫秒，但异步 I/O 模型通常能显著改善并发等待。
分步处理
第一步：定位耗时分布
在 Server 代码的关键路径（接收请求、执行工具、返回结果）打入时间戳日志。对比“接收时间”与“开始执行时间”的差值（传输开销），以及“开始执行”与“执行结束”的差值（业务开销）。
第二步：优化工具执行逻辑
检查 Tool 实现中是否有同步网络请求或磁盘读写。若有，改为异步客户端（如 Python 的 aiohttp，Node.js 的 axios 异步模式）。对于重复查询，引入内存缓存（如 TTL 缓存），避免重复 I/O。
第三步：调整传输与并发模型
若当前使用 STDIO 传输，且并发量大，考虑切换为 SSE（Server-Sent Events）传输模式，减少进程间通信开销。检查 Server 是否限制了最大并发连接数，适当调大工作线程池或协程限制。
第四步：设置超时与熔断
为每个 Tool 调用设置明确的超时时间（如 100ms），防止单个慢请求拖垮整体响应。当外部依赖不可用时，快速失败而非无限等待。
怎么验证是否生效
使用压测工具（如 wrk 或自定义脚本）模拟高并发 MCP 请求。观察监控面板中的 P99 延迟是否稳定在 200ms 以内。检查 Server 日志，确认没有大量的超时错误或连接重置记录。对比优化前后的吞吐量（Requests Per Second），在延迟达标的前提下吞吐量应有所上升。
常见坑
- 缓存一致性：引入缓存后，若底层数据变更，需确保缓存失效策略生效，避免返回 stale 数据。
- 资源泄露：高并发下未正确关闭数据库连接或 HTTP 客户端，会导致句柄耗尽，进而增加延迟。
- 日志阻塞：同步写入大量日志到磁盘会占用 I/O 线程，建议改为异步日志或降低日志级别。
- 传输模式误用：STDIO 适合本地调试，生产环境高并发建议优先评估 SSE 或 HTTP 流式传输。
常见问题
MCP Server 默认支持多少并发？
没有固定值，取决于具体实现语言和服务器配置。官方规范未规定并发上限，需通过压测确定当前硬件下的瓶颈。
切换 SSE 传输模式需要改客户端吗？
需要。Client 和 Server 必须协商一致的传输协议，切换 Server 端后，Client 连接配置也需相应调整为 SSE 端点。
缓存会导致 AI 拿到旧数据吗？
会。若工具数据实时性要求高，应缩短缓存 TTL 或针对特定写操作手动清除缓存，需权衡延迟与数据一致性。
参考来源
- 来源名：Model Context Protocol 官方文档
- 页面标题：Model Context Protocol Specification
- URL：https://modelcontextprotocol.io