Cómo medir el rendimiento de Immich sin confundir la caché con la capacidad

La capacidad de Immich debe medirse con cargas de trabajo en frío, en caliente y sostenidas, repetidas varias veces, porque una sola ejecución rápida con caché puede ocultar el verdadero punto de saturación del sistema.

Un servidor doméstico puede hacer que una cronología o un álbum parezcan extremadamente rápidos después de que las mismas miniaturas, páginas de la base de datos y datos de la aplicación ya se hayan utilizado. Ese resultado demuestra que la ruta en caliente es eficiente, no que el sistema pueda mantener una biblioteca familiar más grande o una mayor actividad simultánea. Una prueba de capacidad útil debe controlar el estado de la caché, ampliar el conjunto de trabajo, repetir las ejecuciones y definir una condición de parada medible.

La velocidad de la caché no es lo mismo que la capacidad

La capacidad describe cuánto trabajo representativo puede mantener un sistema Immich antes de que la latencia, las colas o los errores resulten inaceptables. La velocidad de la caché responde a una pregunta más limitada: ¿con qué rapidez puede el sistema repetir una tarea después de que los datos útiles o los recursos generados ya están cerca? Si una prueba repite el mismo álbum o cronología, ambas preguntas pueden parecer idénticas, aunque midan condiciones operativas diferentes.

La diferencia se aprecia fácilmente en el rendimiento web, donde los tiempos de la primera visualización y las visualizaciones repetidas pueden divergir porque las solicitudes posteriores reutilizan recursos almacenados en caché. Immich ofrece oportunidades adicionales para el comportamiento en caliente, ya que pueden reutilizarse miniaturas, vistas previas, páginas de la base de datos, metadatos del sistema de archivos, la caché del sistema operativo y recursos del cliente. Por tanto, una ejecución repetida puede eliminar trabajo que una biblioteca en crecimiento o recién accedida todavía debe realizar.

Esta es la misma razón por la que una prueba de Home Assistant centrada en la caché puede inducir a error cuando predominan las solicitudes repetidas; el análisis de ZimaSpace sobre las capas de caché para solicitudes repetidas también se aplica aquí a la lógica de medición. En Immich, registra el rendimiento en caliente, pero etiquétalo como una ruta independiente en lugar de tratarlo como la capacidad general del servidor.

Separa las ejecuciones en frío, en caliente y en estado estable

Empieza definiendo el estado antes de poner en marcha el cronómetro. Una ejecución en frío debe incluir trabajo que no se haya repetido recientemente, como abrir un intervalo de fechas o un conjunto de recursos diferente después de que las cachés hayan tenido menos oportunidades de ayudar. Una ejecución en caliente repite deliberadamente una ruta conocida. Una ejecución en estado estable mantiene una actividad representativa durante el tiempo suficiente para revelar el trabajo en segundo plano, la reutilización de recursos y las colas que una ráfaga breve quizá nunca muestre.

El calentamiento también puede ser engañoso. Percona describe casos en los que una base de datos parece estar caliente mientras los procesos en segundo plano retrasados siguen modificando el rendimiento, por lo que el estado estable llega después de las primeras consultas rápidas. De forma similar, Immich puede solapar la navegación en primer plano con la actividad de la base de datos, el procesamiento de miniaturas, la indexación u otras tareas en cola, según lo que esté haciendo la biblioteca en ese momento.

Para una prueba en un servidor doméstico, ejecuta cada fase por separado en lugar de promediarlas. Anota si las tareas en segundo plano están inactivas o activas, mantén constantes el cliente y la ruta de red, y repite varias veces la misma fase. Si la ejecución en caliente es rápida, pero la actividad sostenida eleva gradualmente la latencia o la profundidad de la cola, el segundo resultado es la mejor señal para planificar la capacidad.

Haz que el conjunto de trabajo sea mayor que la caché fácil

Una prueba que abre las mismas veinte fotos normalmente es demasiado pequeña para responder a una pregunta sobre la capacidad de una biblioteca familiar. El sistema operativo, la base de datos, el cliente y la pila de almacenamiento pueden mantener un pequeño conjunto activo cerca del procesador, mientras que el uso real alterna entre meses, personas, álbumes, resultados de búsqueda y vídeos. Por tanto, el conjunto de prueba debe ser lo bastante grande y variado como para que no todas las operaciones se beneficien de los mismos datos utilizados recientemente.

Las prácticas de evaluación comparativa de bases de datos hacen explícita la distinción: cuando una prueba pretende examinar el almacenamiento o el comportamiento en frío, la caché residual puede convertir el ejercicio en una prueba del rendimiento de la caché. No es necesario vaciar todas las capas de caché de un servidor Immich en producción para obtener información útil, pero sí necesitas una carga de trabajo cuyo conjunto de trabajo sea más amplio que una sola pantalla reutilizada repetidamente.

Elige varios intervalos de fechas, álbumes, búsquedas y tipos de recursos que se parezcan al uso normal de un hogar, y alterna entre ellos en lugar de insistir en una sola vista. Conserva esa definición de la carga de trabajo al comparar hardware o configuraciones. Si un cambio solo mejora un pequeño subconjunto repetido mientras la navegación más amplia sigue degradándose bajo carga, ha mejorado la ruta en caliente sin ampliar el límite de capacidad útil.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mide percentiles y repite la prueba

Un solo promedio puede ocultar los momentos que los usuarios realmente perciben. Si nueve solicitudes son rápidas y la décima se bloquea mientras crece una cola o el almacenamiento está ocupado, la media todavía puede parecer aceptable. Registra al menos el comportamiento mediano y un percentil de cola, como p95, y relaciona la latencia con el rendimiento, el número de errores, el trabajo pendiente, la CPU, la presión de memoria y la actividad de almacenamiento para contextualizar la ralentización.

El análisis práctico de pruebas comparativas recomienda informar de p50, p95, p99 y la variación, en lugar de confiar en una sola ejecución, especialmente en sistemas con estado donde la expulsión de caché, la compactación o la actividad en segundo plano pueden aparecer más tarde. Las pruebas de Immich no necesitan precisión de laboratorio, pero sí suficientes repeticiones para distinguir un límite reproducible de un intervalo afortunadamente tranquilo.

Ejecuta el mismo escenario al menos varias veces en cada nivel de carga y conserva las observaciones sin procesar, en lugar de guardar solo la mejor ejecución. Una afirmación sobre la capacidad resulta más creíble cuando p95 se mantiene estable entre ejecuciones y el servidor vacía el trabajo en cola entre ventanas. Si los resultados varían mucho, investiga la variable no controlada antes de afirmar que más usuarios, más fotos o un hardware más rápido han cambiado el límite.

Usa un protocolo de capacidad de Immich con una condición de parada

Empieza con una carga de trabajo representativa de un cliente y registra una línea base después de que el sistema alcance el estado que pretendes probar. Después, incrementa una sola variable a la vez: más navegación simultánea, cargas, búsquedas o procesamiento en segundo plano, manteniendo fijos la biblioteca, la combinación de clientes, la ruta de red y la configuración del servidor. En cada paso, registra la latencia p50 y p95, las operaciones correctas por minuto, los errores, el crecimiento de la cola y el recurso principal del servidor que se acerca a la saturación.

Este enfoque evita el error habitual de extraer conclusiones de una sola ejecución breve. Las buenas prácticas de pruebas de rendimiento advierten contra las conclusiones basadas en una sola ejecución, porque el calentamiento, el estado de la caché, el trabajo en segundo plano y el ruido normal del sistema pueden dominar una muestra. Repite cada nivel de carga hasta que la tendencia sea lo bastante estable como para explicarla, no solo lo bastante conveniente como para citarla.

Define una regla de parada antes de realizar la prueba. Un criterio práctico para un laboratorio doméstico es considerar saturada la configuración actual cuando la latencia p95 se mantiene por encima de aproximadamente el doble de la línea base sin carga durante tres ventanas de medición consecutivas, o cuando los errores o el trabajo pendiente siguen creciendo en lugar de recuperarse; se trata de una heurística de prueba, no de un límite de Immich. La cifra de capacidad útil es el último nivel de carga por debajo de ese límite, medido con el mismo protocolo en frío, en caliente y en estado estable.