酒店在采购网络审计网关时，很多人关注的是价格和品牌，或者厂商给出的"支持多少用户"这个简单数字。但实际上，决定一台审计网关在真实环境下能不能稳定运行的，是几个具体的性能参数。这些参数在产品资料里不一定写得显眼，但忽略它们的代价，往往是设备上线后出现各种预料之外的问题。

并发会话数

并发会话数是指审计网关在同一时刻能够跟踪和处理的网络连接数量。每台设备连接到网络后，哪怕只是后台同步数据，也会产生多条并发会话。一个 200 间客房的酒店，入住率 80% 的情况下，活跃设备大约在 320 台以上，每台设备平均 20-30 条并发会话就已经超过一万条了。如果审计网关标称的并发会话数只有 8000 或 10000，高峰期就会出现会话溢出，导致部分连接的审计记录丢失，甚至影响正常上网体验。选型时应该根据酒店的实际客房数量和设备密度估算峰值并发量，留出至少 50% 的余量。

吞吐量与线速处理能力

吞吐量是审计网关能够处理的最大带宽。如果酒店的互联网出口是 200Mbps，审计网关的最大吞吐量至少要超过这个数字，否则网关本身会成为带宽瓶颈。需要注意的是，很多厂商标注的吞吐量是"理想状态下的最大值"，而不是开启全部审计功能时的实际吞吐量。开启深度包检测、日志记录、流量分析等功能后，实际吞吐量可能下降到标称值的 50%-70%。选型时需要明确询问"开启完整审计功能后的实际吞吐量"，而不能只看标称值。

新建会话速率

新建会话速率（CPS，Connections Per Second）指的是审计网关每秒能够新建的连接数量。这个参数在酒店早餐时段、退房高峰期等场景特别重要——大量住客在短时间内同时打开手机、刷新 App、发送消息，会产生大量的新建连接请求。如果新建会话速率不够高，这些新连接就会排队等待，住客会感受到明显的网络卡顿。低端审计设备的新建会话速率通常只有几百到几千，对于大型酒店来说往往不够用。

日志写入速度

审计网关需要把每条会话记录写入存储设备。如果日志写入速度跟不上会话产生的速度，系统会建立一个写入队列缓冲。在流量高峰期，如果写入速度持续落后，队列会越来越长，最终要么导致旧日志被丢弃，要么系统因为缓冲区满而崩溃。日志写入速度取决于存储介质的类型（固态硬盘比机械硬盘快很多）和系统的 I/O 设计。很多低价审计设备用的是机械硬盘，在高流量环境下日志写入是一个明显的瓶颈。

CPU 和内存的实际配置

审计网关是一台运行审计软件的计算机，CPU 和内存的配置直接影响它能承受的负载上限。很多厂商不公开这些基础参数，或者用模糊的表述来回避。在采购决策前，可以要求厂商提供设备的 CPU 和内存规格，或者在相近规模的参考客户处做压力测试。一台 CPU 核心数不足、内存只有 2-4GB 的审计设备，在流量高峰期 CPU 占用率可能长期维持在 90% 以上，系统响应变慢，日志处理延迟增大。

高可用性配置的支持

审计网关串联在网络出口时，如果设备出现故障，整个酒店的网络访问就会中断。对于审计工作可以接受短暂中断的场景，一台设备就够了；但对于需要 7×24 小时不间断服务的酒店，就需要考虑双机热备或硬件 Bypass 功能。双机热备是部署两台设备，主设备出故障时自动切换到备用设备；Bypass 功能是设备断电或故障时，网络流量可以直接通过，不经过审计（代价是这段时间没有审计记录）。这两种方案各有适用场景，选型时应该根据酒店的业务连续性要求来决定。

查询接口的响应性能

审计设备存储了大量日志，但查询效率如果很低，日志数据实际上很难用。查询某个 IP 在某个时间段的访问记录，如果需要等待几分钟才能出结果，紧急情况下就会严重影响响应速度。查询接口的响应性能取决于日志存储的索引设计，一些设备有针对常用查询条件（IP、时间段、用户 ID）的专用索引，查询速度快；一些设备没有索引，全扫描查询，日志量大了以后速度很慢。这个参数在选型演示时一定要实测，不能只看厂商的文字描述。

扩展性的设计

酒店的客房数量可能增加，网络出口带宽也可能随着业务发展而扩容。审计网关的性能是否支持通过升级许可或扩展硬件来提升，而不必更换整台设备，这也是一个值得在选型阶段确认的问题。买了一台在当前规模下刚好够用的设备，如果酒店三年后扩建了，设备又不支持扩展，又要重新采购，初期省下来的钱可能还不够后面的更换成本。

性能参数的背后是真实的使用场景。选型不是挑价格最合适的，而是找在实际负载下能稳定运行的那一台。