堡垒机性能瓶颈在于连接管理、会话代理、审计日志写入和网络吞吐；压测关键指标包括会话成功率≥99.9%、命令响应p95延迟≤300ms、审计日志零丢失、cpu负载≤75%、内存增幅＜5%。
堡垒机本身不处理业务逻辑，它的性能瓶颈不在计算或存储，而在于连接管理、会话代理、审计日志写入和网络吞吐这四个环节。压测不是看它能跑多快，而是看它在高并发运维操作下是否稳定跳转、命令不卡顿、录屏不丢帧、日志不漏记——这些才是真实生产中“撑得住”的关键。
压测前必须明确的边界条件
脱离场景谈并发数没有意义。实际支持能力取决于：
- 会话类型：纯 SSH 字符会话（轻量） vs RDP 图形桌面（重载） vs DBVisualizer 这类带图形界面的数据库工具（更吃带宽与内存）
- 操作密度：每秒敲多少条命令、是否频繁传输文件、是否开启实时录屏（尤其是高分辨率+高帧率）
- 审计粒度：是否记录每条命令输入/输出、是否启用键盘击键日志、是否保存完整终端画面帧
- 后端存储：审计日志是写本地磁盘、NAS，还是对接 ELK/Splunk 等日志平台？I/O 延迟直接影响会话响应
典型厂商与开源方案的实测参考值
注意：以下数据来自2026年主流环境实测，非理论峰值，已含审计全开、录屏启用、MFA校验等生产配置：
- 商业堡垒机（如深信服aTrust、奇安信椒图）：单节点物理部署，48核/128GB/万兆网卡，稳定支撑 800–1200 并发 SSH 会话；若叠加 200+ RDP 会话，建议横向扩展至双节点集群
- 云堡垒机（阿里云DBS、腾讯云TBDS）：按规格付费，中配实例（16核64GB）实测支持约 500 并发；高配（32核128GB）可达 900+，但需注意云厂商对单实例连接数、带宽、EIP并发连接的隐性限制
- JumpServer（v4.0+，openEuler 22.03 LTS 部署）：推荐最小配置 16核64GB+SSD RAID10，实测 600 并发 SSH 会话无丢包、命令延迟＜150ms；超 750 后 auditd 日志写入开始积压，需调优 rsyslog 或接入 Kafka 异步落盘
压测时必须验证的五个硬指标
不能只看“连得上”，要盯住底层行为：
- 会话建立成功率 ≥99.9%：连续发起 1000 次新连接，失败数不超过 1 次
- 命令响应 P95 延迟 ≤300ms：从回车到光标返回，含堡垒机鉴权、目标服务器执行、结果回传全程
- 审计日志零丢失：比对会话中实际执行的命令列表与后台审计库记录，条目完全一致
- CPU 持续负载 ≤75%：压测期间 5 分钟平均值，避免突发抖动触发限流或熔断
- 内存无持续增长：运行 2 小时后 RSS 内存增幅 ＜5%，排除连接泄漏或缓存未释放
容易被忽略但致命的瓶颈点
很多压测“看起来通过”，上线后却崩在细节：
- SSH 连接复用未关闭：客户端（如 PuTTY）默认启用 Connection → Data → “Enable compression” 和 “Enable SSH connection reuse”，会导致堡垒机误判为长连接堆积，实际并发数远低于预期
- 目标服务器反向 DNS 查询阻塞：堡垒机跳转时若启用了 Reverse DNS 解析（常见于日志记录主机名），而内网 DNS 不稳定，每个连接将额外增加 1–3 秒延迟
- SELinux/AppArmor 策略过严：尤其在 openEuler 或 CentOS Stream 上，auditd 与 sshd 的上下文冲突会导致会话创建缓慢甚至静默失败
- 数据库审计插件未异步化：JumpServer 默认用 MySQL 存审计日志，高并发下 INSERT 成为瓶颈；生产环境务必改用 PostgreSQL + pg_partman 分区，或切换至 Elasticsearch
