Cómo comparar el rendimiento de Immich con una carga de trabajo repetible en un servidor doméstico

Un benchmark reproducible de Immich fija el conjunto de archivos multimedia, la ruta del cliente, el estado de la caché, la actividad en segundo plano y el punto final medido antes de cambiar una sola variable.

Sin esos controles, una segunda ejecución más rápida puede reflejar datos en caché y no un hardware mejor, mientras que una prueba en reposo puede ocultar la contención durante la importación. Un benchmark útil para un servidor doméstico reproduce, en la misma secuencia, las demandas reales del hogar de navegación, carga, búsqueda y recuperación.

Define los resultados para el usuario antes de recopilar métricas

Empieza con resultados observables, como la aceptación de una carga, el tiempo hasta que una foto nueva se pueda buscar, la finalización de las miniaturas de la cronología, la apertura del original, el inicio de un vídeo o la recuperación de una biblioteca utilizable. El uso de la CPU y el rendimiento del disco explican estos resultados, pero no sustituyen el resultado de cara al usuario.

El artículo sobre la ruta de datos de Immich de ZimaSpace separa la aceptación de la carga, la disponibilidad para el procesamiento, la selección de búsqueda y la entrega del contenido multimedia. Esta estructura es útil porque un benchmark debe medir el tiempo de un punto final, en lugar de combinar varias etapas dependientes en un total engañoso.

Selecciona dos puntos finales interactivos y uno en segundo plano. Define un objetivo de aprobación para cada uno y registra la mediana junto con la latencia de la cola lenta o la tasa de finalización. Un benchmark con muchas puntuaciones no relacionadas se vuelve difícil de interpretar; un conjunto reducido vinculado a una decisión concreta mantiene el resultado en condiciones de ser aplicado.

Congela el conjunto de datos, la ruta del cliente y el estado inicial

Usa las mismas fotos y vídeos representativos en cada ejecución, incluidos los formatos y tamaños que coincidan con la biblioteca familiar. Fija la cuenta, el dispositivo cliente, la ruta de red, la versión de Immich y la configuración de los derivados. Incluso un cambio en la caché del navegador o en la ruta Wi-Fi puede eclipsar la diferencia de configuración que se está probando.

Un artículo sobre benchmarks de búsqueda vectorial destaca la importancia de usar cargas de trabajo reproducibles de generación de embeddings, inserción y recuperación al estudiar el rendimiento de búsqueda de PostgreSQL. Immich es una aplicación más amplia, pero el principio experimental se aplica igualmente: se necesitan entradas controladas y operaciones de recuperación definidas antes de que las diferencias de tiempo respalden una conclusión.

Crea un manifiesto del conjunto de datos que contenga sumas de comprobación de los archivos, cantidades, totales de bytes, formatos de fotos, duraciones de vídeos y resultados de búsqueda esperados. Añade una lista de comprobación inicial para los servicios reiniciados, las acciones de calentamiento, las tareas en cola y las aplicaciones en competencia. Si la lista de comprobación difiere, marca la ejecución como no comparable en lugar de promediarla.

Ejecuta fases en frío, en caliente y sostenidas

La fase en frío revela el coste de inicialización y del primer acceso. La fase en caliente revela la reutilización mediante la repetición inmediata. La fase sostenida combina interacciones repetidas con una importación representativa o una cola en segundo plano durante el tiempo suficiente para revelar la limitación térmica, la presión de memoria, las colas de almacenamiento y la competencia por recursos.

Un informe de la comunidad describe una primera búsqueda inteligente que tarda unos cinco segundos y una repetición inmediata de alrededor de medio segundo mientras cambia el uso de memoria del modelo. Esas cifras no son un estándar de benchmark; demuestran por qué promediar solicitudes en frío y en caliente oculta la transición que la prueba debe explicar.

Ejecuta cada fase al menos tres veces y conserva las marcas de tiempo sin procesar y los registros de recursos. Mantén la mediana y una medida de la cola lenta para el trabajo interactivo, además de los elementos procesados por minuto para el trabajo en segundo plano. Detén la ejecución si los errores, las tormentas de intercambio o los límites térmicos invalidan la condición estable prevista.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Usa una hoja de ejecución con una sola variable

Escribe la hipótesis antes de la ejecución: cambiar la ubicación de la base de datos, la concurrencia de los trabajadores, el límite de memoria, la ruta de red o el acelerador debería mejorar un punto final concreto mediante un mecanismo indicado. Mantén todo lo demás fijo. Esto evita que una actualización con varios cambios produzca un resultado más rápido sin una causa defendible.

Un análisis general de los cuellos de botella explica que los límites de CPU, RAM, almacenamiento y red producen patrones de uso y efectos distintos para el usuario. Aplicado a Immich, las métricas de apoyo deberían cambiar de forma coherente con el punto final; el gráfico más activo no es automáticamente el componente limitante.

Registra los resultados de referencia y los modificados para las fases en frío, en caliente y sostenidas; después, marca cada uno como aprobado, suspendido o inconcluyente. Rechaza las mejoras que desaparezcan al repetir la prueba o que provoquen errores, temperaturas inestables, pérdida del progreso de la cola o una recuperación más lenta. Conserva el manifiesto y la hoja de ejecución para que una versión futura pueda compararse de forma honesta.