¿Cuántos usuarios simultáneos puede gestionar Immich antes de ralentizarse?

No existe un número universal útil de usuarios simultáneos de Immich que todos los servidores domésticos puedan gestionar, porque «un usuario» puede significar navegar sin actividad, buscar rostros, realizar una carga grande, reproducir un video o ejecutar varios trabajos en segundo plano a la vez.

La capacidad debe medirse como la mayor carga de trabajo doméstica repetible que siga cumpliendo tus propios criterios de tiempo de respuesta y errores. Establece una línea base en reposo, reproduce acciones mixtas realistas, aumenta la concurrencia en pasos controlados y observa cuál es el primer recurso que se satura. Así obtendrás un rango de capacidad defendible para tu hardware y tu biblioteca, en lugar de un límite de usuarios inventado.

Define qué significa «se ralentiza» antes de contar usuarios

Elige un conjunto reducido de acciones visibles para el usuario que sean importantes en tu hogar: abrir la cronología, cargar un álbum antiguo, buscar, reproducir videos y cargar un lote. Decide qué se considerará un fallo antes de la prueba, como una latencia inaceptable, tiempos de espera agotados, cargas fallidas, interrupciones en la reproducción o una cola que siga creciendo después de que los usuarios se detengan.

No mezcles el trabajo en primer plano y en segundo plano sin registrarlo. La generación de miniaturas, la transcodificación de videos, el procesamiento de rostros, Smart Search, los escaneos de la biblioteca, el mantenimiento de la base de datos y las copias de seguridad pueden consumir los mismos recursos de CPU, memoria, disco y red que los usuarios activos. Una prueba con «cuatro usuarios» durante una importación grande representa una carga de trabajo diferente a la de cuatro personas navegando por una biblioteca estable.

Registra el hardware, la versión de Immich, la ubicación de la base de datos, el tipo de almacenamiento, el enlace de red, el tamaño de la biblioteca y los trabajos en segundo plano activos con cada resultado. Sin ese contexto, un número de concurrencia no puede compararse de forma significativa después de una actualización ni con otro servidor doméstico.

Mide una línea base de un usuario con el trabajo en segundo plano bajo control

Comienza cuando el sistema se encuentre en un estado conocido y mide un recorrido representativo de un usuario. Registra el tiempo de respuesta del cliente junto con la CPU del servidor, la presión de memoria, la latencia o utilización del disco, el rendimiento de la red, la actividad de la base de datos y cualquier cola de trabajadores de Immich que puedas observar.

Una afirmación sobre capacidad solo es significativa cuando la carga de trabajo, la duración de la prueba y los criterios de éxito están definidos explícitamente. Utiliza pruebas de capacidad basadas en la carga de trabajo para guardar una línea base de un usuario y, después, mide cómo cambian la latencia, el rendimiento y los errores a medida que aumenta la concurrencia.

Si un usuario ya experimenta lentitud, detén la prueba de concurrencia. Soluciona primero el cuello de botella de un solo usuario; añadir más sesiones solo amplifica un problema existente de almacenamiento, base de datos, CPU, red o configuración, y aporta poca información sobre el verdadero comportamiento de escalado del servidor.

Aumenta la concurrencia realista en pasos controlados

Añade usuarios o sesiones de cliente mediante scripts gradualmente, manteniendo una mezcla de acciones similar entre cada paso. Una secuencia doméstica útil podría duplicar las sesiones activas desde una línea base pequeña, pero los números exactos son menos importantes que cambiar solo la concurrencia y mantener constante la definición de la carga de trabajo.

Define los límites de latencia, errores y rendimiento antes de realizar la prueba, y utiliza recorridos realistas de varios pasos en lugar de bombardear un único endpoint. Una carga de trabajo realista para pruebas de carga de Immich debe combinar las acciones que tu hogar realiza realmente, en lugar de tratar las solicitudes de inicio de sesión repetidas como un indicador de la capacidad de un servidor de fotos.

Mantén cada paso el tiempo suficiente para que las cachés, las colas, las conexiones de la base de datos y la demanda de almacenamiento se estabilicen. Registra tanto el pico como la capacidad del sistema para recuperarse cuando se retire la carga. Un servidor que parece aceptable durante un breve pico, pero deja una cola de trabajos cada vez mayor, ya ha superado un nivel sostenible para esa carga de trabajo.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Identifica el primer recurso que se satura

Cuando la latencia aumente, correlaciona la marca de tiempo con el comportamiento de los recursos. La saturación de la CPU durante las búsquedas o el aprendizaje automático sugiere presión de procesamiento; una latencia elevada del disco con una CPU moderada apunta a la base de datos o al almacenamiento multimedia; los enlaces de red saturados indican límites de transferencia o acceso remoto; y el aumento de las esperas de la base de datos o la presión sobre las conexiones apuntan a la capa de datos.

Los trabajos en segundo plano pueden cambiar el resultado, porque la generación de miniaturas, la transcodificación, el aprendizaje automático, los escaneos, las copias de seguridad o los bucles de reintento pueden consumir recursos incluso cuando nadie está navegando activamente. Compara la prueba con las condiciones de carga en segundo plano de Immich bajo control, para no confundir el trabajo programado con un límite bajo de usuarios.

No «soluciones» la capacidad ocultando los errores con tiempos de espera del cliente más largos. Cambia el recurso limitante o la política de carga de trabajo —por ejemplo, programando los trabajos pesados, mejorando la ubicación del almacenamiento, reduciendo las transcodificaciones simultáneas o añadiendo capacidad de procesamiento— y vuelve a reproducir exactamente el paso que falló para demostrar que el cuello de botella se desplazó o desapareció.

Establece un rango práctico de capacidad doméstica y vuelve a probarlo

Define la capacidad práctica como la mayor concurrencia probada en la que todos los recorridos de usuario necesarios se mantienen dentro de tus límites preestablecidos de latencia y errores, las colas regresan hacia la línea base después de la prueba y el equipo conserva suficiente margen para el trabajo habitual en segundo plano. Exprésala como un rango específico de la carga de trabajo, no como un máximo general de Immich.

Repite al menos una vez el paso límite desde un estado limpio y comparable, e incluye las acciones que anteriormente provocaron una degradación. Después, prueba brevemente el siguiente paso superior para confirmar que el límite sigue apareciendo en el mismo recurso, sin llevar el sistema a una cola incontrolable ni a un evento de presión de almacenamiento.

Vuelve a ejecutar la misma prueba después de actualizaciones importantes de Immich, cambios de ubicación de la base de datos, modificaciones del almacenamiento o del hardware, o un aumento considerable del tamaño de la biblioteca. Tu número de capacidad es una propiedad del sistema y la carga de trabajo actuales; conservar la receta de la prueba es más valioso que conservar un recuento antiguo de usuarios.