¿Cuántos núcleos necesita OpenVPN? Depende de la ruta
Un solo flujo puede fijar un núcleo mientras el servidor parece inactivo. Compare la ruta en el espacio de usuario con la descarga en el núcleo y luego mida la concurrencia que realmente atiende.
Dos servidores con el mismo número de procesadores pueden sostener un rendimiento muy distinto, porque el número que importa es cuántos núcleos puede aprovechar de verdad la ruta de datos activa. Un solo demonio en el espacio de usuario que procesa los paquetes de un cliente está limitado a un núcleo, mientras que una ruta del núcleo con descarga puede repartir ese trabajo. Ninguna de las dos afirmaciones dice qué hará una máquina concreta con su tráfico, por eso la medición va antes que el recuento de núcleos.
La comparación de abajo trata de dónde se procesan los paquetes, no de qué producto es más rápido en abstracto. Son preguntas distintas con respuestas distintas.
Un núcleo por flujo en la ruta del espacio de usuario
En una instancia tradicional de Community OpenVPN el canal de datos se procesa en el espacio de usuario, y una conexión ocupada puede fijar un procesador mientras la utilización global de la máquina sigue siendo discreta. Por eso añadir núcleos a un servidor ya saturado en un solo flujo no cambia nada: el planificador no tiene forma de dividir ese trabajo. La estructura de un proceso por cliente limita la transferencia de un cliente a la capacidad de un núcleo, sea cual sea el número total de núcleos. Lea la utilización por núcleo durante una prueba en lugar de la cifra agregada, o el cuello de botella parecerá margen libre.
Ejecutar varias instancias de servidor en un solo equipo reparte clientes separados entre procesos. No paraleliza una conexión existente y cuesta grupos, escuchadores y decisiones de enrutamiento separados.
La otra ruta: paquetes en el núcleo
Descarga del canal de datos traslada al núcleo el procesamiento de paquetes compatible y la criptografía, donde el trabajo puede usar varios núcleos. Eso cambia la pregunta de capacidad de un núcleo a la máquina, pero solo para configuraciones que la implementación admite: un módulo del núcleo compatible, un cifrado de datos apto y una configuración sin las funciones que la descarga excluye. Instalar un módulo no es lo mismo que usarlo, así que confirme el modo activo a partir del registro o de la salida de estado de la propia conexión. Un cartel de versión demuestra qué está disponible, no qué se está ejecutando.
La descarga no elimina la autenticación ni el canal de control, y no convierte cada despliegue en uno de varios núcleos. Es una aceleración local de una ruta de datos compatible, y los requisitos cambian según la plataforma y la versión.
Qué decide realmente la comparación
La elección real está entre aceptar un techo por flujo, repartir clientes entre instancias y pasar a una configuración de descarga admitida. Cada una atiende un problema distinto, y elegir la equivocada cuesta dinero sin mover la cifra. La prueba que importa es la que tiene la forma de cómo se usa el servicio.
Mida tres formas: un cliente con una transferencia, un cliente con varios flujos y varios clientes a la vez. Un total alto en la tercera no demuestra que una sola descarga pueda alcanzarlo, y una transferencia individual lenta no demuestra que el servidor haya agotado su capacidad global. Los resultados responden a preguntas distintas y ambos merecen la pena.
Solo la forma intermedia le dice si la concurrencia dentro de un cliente ayuda, lo que normalmente es una propiedad del transporte y de la ruta más que del servidor. Solo la primera le dice el techo que verá una sola aplicación. Mantenga la carga idéntica entre ejecuciones para que la comparación signifique algo.
Medir para que la cifra signifique algo
Anote las versiones del servidor y del cliente, la ruta de datos activa, el cifrado de datos negociado, la dirección de la transferencia, los tamaños de paquete, el número de flujos y la duración. Vigile la actividad por núcleo y las pérdidas de paquetes y de colas en ambos extremos, porque la interfaz del propio cliente, la red del proveedor o el servicio de destino pueden convertirse antes en el límite. Cambie una variable cada vez, ya que una ejecución que altera cifrado, compresión, MTU y descarga a la vez no puede decirle cuál importó. Mantenga durante la prueba la política de acceso que realmente piensa desplegar, porque una disposición de laboratorio que nadie ejecutará demuestra poco.
Después deje margen para el canal de control, para la renegociación y para todo lo demás que corre en el equipo.
Informe de lo que sostuvo la configuración bajo la concurrencia prevista, en lugar de una tasa extrapolada del hardware de otra persona. Una cifra con sus condiciones de prueba adjuntas es útil; una promesa sin ellas es una conjetura que le devolverán citada.