OpenVPN 需要几个核心？取决于路径

两台处理器数量相同的服务器可能承受完全不同的吞吐量，因为真正关键的数是活跃数据路径实际能用到几个核心。处理单个客户端数据包的用户空间守护进程受限于一个核心，而卸载到内核的路径可以把这项工作分摊开。这两种说法都没有告诉你某台机器对你的流量会怎样，所以先测量，再数核心。

下面的比较关心的是数据包在哪里被处理，而不是抽象地说哪个产品更快。这是两个不同的问题，答案也不同。

用户空间路径上每条流占一个核心

在传统的 Community OpenVPN实例中，数据通道在用户空间处理，一条繁忙的连接可能占住一个处理器，而整机利用率看起来并不显眼。正因如此，给已经卡在单条流上的主机增加核心毫无变化：调度器没有办法拆分那份工作。每个客户端一个进程的结构，把单个客户端的传输限制在一个核心的能力之内，无论总核心数是多少。测试时要看每个核心的利用率，而不是汇总数字，否则瓶颈会被当成余量。

在一台主机上运行多个服务器实例，会把不同的客户端分摊到不同进程。它并不会让已有连接并行化，而且需要独立的连接池、监听器和路由决策。

另一条路径：把数据包放进内核

数据通道卸载把受支持的数据包处理和加密搬进内核，那里的工作可以用到多个核心。这把容量问题从一个核心变成整台机器，但只适用于实现所支持的配置：兼容的内核模块、符合要求的数据加密算法，以及不包含卸载所排除特性的配置。装了模块不等于在用模块，所以要从连接自身的日志或状态输出确认当前模式。版本横幅只能证明有什么可用，不能证明正在运行什么。

卸载既不去掉认证，也不去掉控制通道，更不会让每个部署都变成多核。它只是对兼容数据路径的本地加速，要求随平台和版本而不同。

比较究竟决定什么

真正的选择在三种做法之间：接受每条流的天花板、把客户端分散到多个实例、或者迁移到受支持的卸载配置。每一种解决的是不同问题，选错会花钱却不动数字。真正重要的测试，是形状与实际使用方式一致的那种。

测三种形状：一个客户端做一次传输、一个客户端开多条流、以及多个客户端同时进行。第三种的总量高，并不证明单次下载能达到那个数；单次传输慢，也不证明服务器的总容量已经用尽。两种结果回答的是不同问题，都值得保留。

只有中间那种形状能告诉你单个客户端内部的并发是否有用，这通常是传输和路径的属性，而不是服务器的属性。只有第一种能告诉你单个应用会看到的天花板。要让比较有意义，各次运行之间必须保持相同的工作负载。

让数字有意义的测量方式

记录服务器与客户端的版本、活跃数据路径、协商出的数据加密算法、传输方向、数据包大小、流数量和持续时间。留意每个核心的活动，以及两端的丢包和队列丢弃，因为客户端自身的网卡、运营商网络或目标服务都可能先成为限制。每次只改一个变量，因为同时改动加密算法、压缩、MTU 和卸载的运行，无法告诉你究竟是哪一项起了作用。测试期间要保留你真正打算部署的访问策略，因为没人会运行的实验室配置证明不了什么。

然后为控制通道、重新协商以及主机上运行的其他一切留出余量。

报告这套配置在预期并发下实际承受住了什么，而不是从别人的硬件外推出来的速率。附带测试条件的数字才有用；没有条件的承诺只是猜测，早晚会被人拿来质问你。