不少企业运维人员在评估现有VPN承载能力、筛选新的VPN部署方案时，都会涉及VPN并发连接数量的横向比对工作，如果直接采信厂商公开的纸面标称参数，很容易出现实际接入远低于标称数量的终端时，就出现隧道卡顿、随机断连、新连接无法建立的异常，想要得到符合自身实际使用场景的准确对比结果，必须在测试过程中逐项记录核心参考数据，排除各类环境变量的干扰，避免测试结论脱离生产实际。
运维人员在VPN测试环境中逐项登记各类并发连接核心参数，保障比对结果贴合实际使用场景
第一类：并发连接的基础属性原始记录
首先要逐一记录每一条并发连接的发起端属性，不能只统计连接的总个数，要明确区分是站点内的终端设备发起的远程接入、异地分支机构的网关级站点对接，还是移动外出人员的单用户拨号连接，不同类型的连接对VPN隧道的资源占用逻辑完全不同，混同统计出来的并发数没有横向对比的参考价值。
还要同步记录每一条连接建立时使用的隧道协议类型，同一台VPN设备下，IPsec协议的单连接资源占用和OpenVPN、SSL VPN的单连接占用存在明显差异，混合不同协议统计出来的并发数值，飞马VPN新手设置无法直接对应同一场景下的承载能力，比对时必须限定相同协议类型再做统计。
第二类：VPN网关侧的实时资源占用数据
在逐步增加并发连接的测试过程中，要全程记录VPN网关的CPU占用率，很多厂商标注的最大并发连接数，是在网关CPU完全不承载其他业务、没有任何额外加密运算负载的理想环境下测得的，实际部署中网关还要处理路由转发、防火墙规则匹配、流量审计等任务，CPU占比达到临界阈值后新增连接会直接被系统拒绝。
接下来要同步记录VPN网关的加密引擎负载情况，开启硬件加密加速的设备，和靠通用CPU做软件加密的设备，相同并发连接数下的剩余处理能力差异极大，这部分数据是区分纸面参数和实际可用并发数的核心依据，很多标称高并发的低价设备，就是靠关闭加密运算的方式跑出虚高的测试结果。
还要记录VPN网关的隧道会话表剩余容量，部分低端VPN设备的会话表项存在底层硬件上限，哪怕CPU、飞马内存资源还有大量剩余，会话表被占满之后也无法新建VPN连接，这类隐性限制很多厂商不会在公开参数里标注，必须通过实测才能记录到准确数据。
第三类：并发连接下的业务可用性校验数据
很多不严谨的测试场景只统计“连接成功建立”的数量，忽略了连接建立之后的实际可用性，比对VPN并发连接数量时，必须记录所有已建立连接的连通性状态，统计有多少条连接可以正常访问对端内网的业务资源，多少条连接出现丢包、延迟突增的异常情况。
还要记录不同并发量级下的新建连接成功率，当连接数接近厂商标注的上限时，部分VPN方案不会直接拒绝新连接，而是出现随机丢包、新连接反复重连的情况，这时候哪怕已经建立的连接总数还没到标称值，实际业务体验已经完全不可用，这类临界状态的连接成功率数据，是判断真实可用并发上限的关键。
第四类：边界场景下的异常状态记录
很多人做VPN并发连接数量：比较时应记录什么的前期规划时，很容易漏掉长时间保活的稳定性相关数据，短时间内批量拨号测出来的并发数，和所有连接保持数小时在线的承载能力完全不同，部分VPN设备的会话老化机制存在漏洞，长时间运行后会出现内存泄漏，实际稳定承载的并发数远低于短时间测试的结果。
还要记录并发连接满负载状态下，新增普通业务规则、调整隧道加密参数时的连接稳定性变化，部分VPN方案在满并发状态下，只要触发配置调整就会批量断开已有连接，这类隐性故障会直接影响生产环境的可用性，也是比对不同方案并发承载能力时必须纳入参考的维度，避免上线后出现非预期的业务中断。
