¿Cuántos usuarios simultáneos puede admitir Plex antes de volverse lento?
No existe un límite universal de usuarios de Plex que sea útil; tu concurrencia estable es la mayor combinación real de sesiones que puede funcionar antes de que el almacenamiento, la red o la transcodificación pierdan margen.
Diez usuarios con reproducción directa pueden ser menos exigentes que dos transcodificaciones remotas demandantes, y un servidor que parece funcionar cómodamente durante una reproducción continua puede sufrir problemas cuando varios espectadores comienzan a reproducir o buscan al mismo tiempo. Cuenta los modos de reproducción reales, las tasas de bits, las rutas de subtítulos y HDR, y el uso de subida para usuarios remotos. Después, añade sesiones representativas una por una y detente ante el primer cuello de botella reproducible, en lugar de estimar la capacidad según el modelo de CPU o el número de cuentas.
Cuenta las rutas de reproducción, no las cuentas
El número de personas que tienen acceso a Plex no es el número de cargas de trabajo simultáneas. Empieza observando el periodo real de mayor actividad y clasifica cada sesión activa como reproducción directa, transmisión directa, conversión únicamente de audio o transcodificación de vídeo. Esos modos consumen recursos del servidor muy diferentes.
Diez o más sesiones simultáneas también pueden producir límites muy diferentes según cuántas rutas de reproducción directa, remultiplexado, conversión de audio y transcodificación de vídeo estén activas. Un recuento bruto de usuarios no puede predecir el punto de ralentización.
Crea un conjunto de pruebas a partir de la coincidencia máxima creíble, no de la lista total de miembros del hogar o amigos. Si seis usuarios rara vez coinciden y todos usan reproducción directa, ese problema de capacidad es distinto al de tres transcodificaciones simultáneas en 4K.
Encuentra el primer recurso compartido que pierda margen
Las sesiones simultáneas comparten el almacenamiento multimedia, la interfaz de red del servidor, el trabajo de CPU para el audio y los subtítulos, el espacio temporal de transcodificación y cualquier motor de vídeo de hardware utilizado para la conversión. El límite lo determina el recurso necesario que falla primero con la combinación real, no el componente con la cifra de especificaciones más alta.
Las cargas de trabajo de Plex con alta concurrencia pueden revelar múltiples cuellos de botella en las unidades, la red, la transcodificación y las rutas de datos internas. Aplica la misma perspectiva de varios recursos a una escala menor de servidor doméstico.
Registra la latencia del disco multimedia, el rendimiento de la red, la CPU, los motores de vídeo de la GPU, la presión de memoria y la velocidad de transcodificación mientras añades sesiones una por una. La primera métrica que pierda margen de forma constante en el mismo punto en que se degrada la calidad de reproducción marca el límite de capacidad útil.
Los usuarios remotos añaden la subida como límite independiente
Las transmisiones locales pueden permanecer completamente dentro de una LAN rápida, mientras que cada transmisión remota comparte la subida a Internet de la conexión doméstica. Incluso un servidor potente puede ralentizarse desde la perspectiva del usuario cuando las tasas de bits combinadas, originales o transcodificadas, superan la capacidad de subida disponible después del resto del tráfico doméstico.
La capacidad remota debe considerar la capacidad de red y de transcodificación como límites independientes. Una GPU más rápida no puede hacer que un enlace WAN sobrecargado entregue más datos.
Prueba la concurrencia remota desde fuera de casa, no abriendo varias pestañas locales del navegador. Si la subida es el primer límite, reduce las tasas de bits remotas o mejora la conexión antes de comprar más CPU. Si la subida sigue teniendo margen y la velocidad de transcodificación disminuye, la ruta de procesamiento es el límite principal.
Los inicios y las búsquedas revelan el margen de ráfaga
La reproducción en estado estable suele ser más sencilla que cuando varios usuarios comienzan a reproducir o buscan al mismo tiempo. Esos momentos generan lecturas en ráfaga, búferes nuevos, solicitudes de metadatos y nuevos flujos de red antes de que la carga se estabilice.
Un número fijo de transmisiones no basta para la planificación de transcodificaciones simultáneas; la prueba de aceptación debe incluir los formatos de archivo, las tasas de bits objetivo, las rutas de subtítulos y el trabajo de conversión que puede iniciarse al mismo tiempo.
Registra el tiempo hasta el primer fotograma y la recuperación tras una búsqueda mientras la combinación de sesiones objetivo ya está activa. Si solo fallan los inicios sincronizados, el límite puede deberse al almacenamiento en ráfaga, la latencia del estado de la aplicación o la espera en cola, y no al procesamiento sostenido.
Los trabajos en segundo plano pueden reducir el mismo margen
Los análisis, las copias de seguridad, las descargas y los trabajos de análisis pueden consumir la misma capacidad de almacenamiento, CPU, memoria o red que necesitan los espectadores activos. Por tanto, un servidor que supera una prueba comparativa en un momento tranquilo puede no alcanzar su pico real de actividad doméstica.
Ejecuta una vez la combinación de sesiones objetivo con el mantenimiento no esencial pausado y otra vez con un trabajo representativo en segundo plano activo. La diferencia muestra si la programación, en lugar de un hardware más grande, puede recuperar margen.
Si la reproducción sigue fallando con los trabajos en segundo plano pausados, mantén el límite de concurrencia en la ruta de reproducción. Si el fallo desaparece, programa o aísla el trabajo que compite y conserva la configuración de servidor de menor coste.
Mantén juntas en el manual operativo las definiciones de las cargas de trabajo que funcionan y las que fallan. Así, el límite operativo puede reproducirse después de cambiar un cliente, un códec, un conjunto de almacenamiento o una tarea programada.
Establece un límite operativo a partir de una prueba repetida
Un límite de concurrencia útil es la combinación de concurrencia estable y reproducible, no el número máximo que reproduce durante treinta segundos. Ejecuta contenido representativo en escenas exigentes, realiza una búsqueda y observa el sistema el tiempo suficiente para que se estabilicen las temperaturas, las colas y la velocidad de transcodificación.
Una prueba de carga remota en 4K dimensiona el hardware solo después de conocer la demanda de reproducción directa, subida y transcodificación, de modo que el límite de concurrencia siga vinculado al trabajo medido y no al número de cuentas.
Documenta la combinación que funciona y el primer modo de fallo. Si una transmisión directa adicional satura la red, tu límite depende de la red. Si una transcodificación adicional cae por debajo del tiempo real, depende del procesamiento. Repite la prueba después de cambios importantes en el cliente, el códec, el almacenamiento o la red, en lugar de tratar el número como permanente.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
