按用户数还是按吞吐量？为真实负载给 VPN 服务器定容

十个闲置账号的成本，还不如一次把隧道跑满的夜间备份；用户数看不出这个差别。给 VPN 服务器定容，本质上是两个数字的比较：你实际承载的并发量，以及最先耗尽的资源。多数容量错误都来自只挑第一个数字、从不测量第二个。按这个顺序两件事都做，硬件决策就不再是猜的。

把账号数与忙时负荷作比较

账号数是许可与支持边界；忙时才是负载。把那一小时里相互重叠的工作列出来：通话、远程管理、大文件下载、备份，以及让人干等的内部应用请求。然后逐项标注它是否穿过网关、朝哪个方向。通话是对称且对时延敏感的，而备份是单向的、能容忍慢启动，因此它们压的是路径的不同部位。

方向决定哪条链路重要。家庭上行链路很少是对称的，一个整天在下载的分支会在网关还没出汗之前就先撞到下行上限。把方向和隧道范围写在每一项旁边，因为只承载内部目标的网关和承载全部互联网流量的网关，是两个不同的定容问题。

把后台负载单独列一行：客户端更新、遥测，以及主机除转发之外做的一切。这些字节很容易被忘掉，而它们同样由同一个接口计数。

找出比链路更早耗尽的资源

链路只是候选之一。单条隧道的加密工作就可能把一个核钉住，而接口还有一半空闲；队列一满，即便图上的吞吐看起来平平，通话也已经不可用。一个只隔一条慢路由的目的地，从客户端座位看也像网关变弱。三种观察可以把这些情况分开，而且都不需要突发测试。

用你有权限运行的传输来测，并且分步叠加并发工作，不要一次全上。把持续速率和交互响应放在一起读，因为只测峰值会掩盖已经不可用的会话。网关跑满最大吞吐、通话却断续，那就不算通过。

然后把可选负载停掉再跑一遍。备份一停就会移动的上限，从来不是网关的上限。

把比较变成一个你守得住的数字

选出耗尽的那种资源，用它的单位来表达需求：忙时目标利用率下的核数、每个方向的比特每秒，或时延上限下的并发会话数。给更新、诊断和恢复留出余量，因为一台坐在实测天花板上的服务器，已经没有余力去做让它继续运行的工作。然后把数字写在产生它们的配置旁边，包括客户端数量和所用测试。

每核用户数是这套练习里最不可移植的数字，因为它假设了下一个站点并不共享的协议组合与设备画像。保留测量，丢掉公式。有人要再加五十个用户的容量时，诚实的答案是那五十人的忙时画像，而不是一次乘法。

记录吞吐的同时也记录响应时间。只保住批量传输的容量，不是给通话中的人的容量，下一次评审会问起这个差别。

在纵向扩容与拆分角色之间选择

当实测上限是单个核时，同频增加核未必有用；更快的核或另一种 worker 模型可能有用。当上限是总 CPU 时，更大的实例是直接解法。当上限是接入链路时，改服务器没有用，比较止于运营商。把 Web 与 VPN 角色拆到不同主机上，是用第二套管理面换隔离。

拿记录下来的数字去比较这些选项，而不是彼此比较。把一个并非瓶颈的资源翻倍，是花钱没有收益；而正是记录让你能不带争论地说出这一点。改完之后用同一负载重测，否则你只是把一个猜测换成了另一个。