¿Cómo afecta la latencia de red a Immich durante las importaciones grandes de bibliotecas móviles?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

La latencia de red afecta más a las importaciones móviles grandes de Immich cuando el flujo de trabajo requiere muchos intercambios de ida y vuelta, reintentos o saltos entre servicios remotos, en lugar de una única transferencia masiva ininterrumpida.

Un enlace de gran ancho de banda puede seguir pareciendo lento si cada solicitud espera un largo recorrido de ida y vuelta, mientras que una LAN de baja latencia puede completar rápidamente las operaciones de control incluso con menos ancho de banda nominal. Sin embargo, una vez aceptado un recurso, la generación de miniaturas, el procesamiento de metadatos y la indexación local pueden continuar sin que el teléfono siga en la ruta crítica, por lo que el retraso de carga y el de procesamiento deben medirse por separado.

La latencia y el rendimiento limitan distintas partes de una importación

El rendimiento determina la rapidez con la que grandes cargas de fotos y vídeos pueden atravesar el enlace cuando la transferencia se mantiene ocupada de forma continua. La latencia determina la rapidez con la que puede completarse un intercambio de solicitud y respuesta, un paso de autenticación, el establecimiento de una conexión o un reintento. La experiencia de importación depende de la combinación de esas operaciones, no de una sola métrica.

La explicación de Tailscale sobre la selección de rutas y los relés muestra por qué una ruta de red puede añadir retraso sin cambiar el propio servidor de Immich. Una ruta directa y una ruta con relé pueden llegar al mismo extremo, pero tener características diferentes de recorrido de ida y vuelta y rendimiento.

Esto significa que una carga formada por muchos archivos pequeños puede ser más sensible al coste de los recorridos de ida y vuelta que un solo vídeo grande del mismo tamaño total. No utilices una única cifra de una prueba de velocidad para predecir la finalización, a menos que la prueba se parezca al patrón y la dirección de las solicitudes de la importación móvil real.

Los reintentos multiplican el coste de un recorrido de ida y vuelta largo

Las pérdidas inalámbricas, los cambios de conexión móvil, las modificaciones de la ruta VPN o los enlaces ascendentes sobrecargados pueden obligar a repetir solicitudes o segmentos. En una ruta de baja latencia, la recuperación puede pasar casi desapercibida; en una ruta de alta latencia, cada reintento añade otro intervalo de espera y puede hacer que el progreso parezca entrecortado.

Un caso real de acceso remoto lento a Immich resulta útil como ejemplo de diagnóstico porque los comentaristas separaron la sospecha sobre la ruta con relé de un problema de configuración del extremo. La lección es verificar tanto la ruta de transporte como el comportamiento de las solicitudes de la aplicación antes de culpar al ancho de banda bruto.

La explicación de red pierde fuerza cuando el servidor recibe los recursos a una velocidad estable, pero las colas en segundo plano siguen avanzando lentamente después de que se detiene la transferencia. En ese momento, el trabajo de la CPU, el almacenamiento, la base de datos o el aprendizaje automático controla la disponibilidad, no la latencia entre el teléfono y el servidor.

El aprendizaje automático remoto añade otro extremo de red

Si la inferencia de aprendizaje automático se ejecuta en otro equipo, la indexación incorpora un salto de red entre el servidor y el sistema de aprendizaje automático que puede no compartir la ruta de carga móvil. Por tanto, un hogar puede tener cargas rápidas desde el teléfono, pero una finalización lenta de la búsqueda semántica cuando el servicio de inferencia es remoto o tiene una conectividad intermitente.

El ejemplo de aprendizaje automático remoto demuestra que Immich ML puede colocarse en otro equipo mediante una red privada. Esa arquitectura puede reducir la presión sobre la CPU local a cambio de depender de la accesibilidad de la red y del tiempo de ida y vuelta entre los servicios.

Mantén este caso separado de la visualización remota normal. Si el sistema de aprendizaje automático está en la misma LAN que el servidor de Immich, la latencia de Internet del teléfono no es relevante para ese paso de inferencia. Si se encuentra al otro lado de un túnel o una WAN, mide esa ruta de servicio por separado.

El tráfico de importación puede competir con el uso remoto interactivo

Una carga grande consume capacidad de subida o de bajada dependiendo de dónde se encuentre el teléfono en relación con el servidor doméstico. Cuando el mismo enlace WAN limitado también transporta imágenes de la cronología, respuestas de la API, copias de seguridad u otro tráfico doméstico, la espera en la cola del router o del extremo del ISP puede aumentar la latencia de las solicitudes interactivas pequeñas.

El análisis de ZimaSpace sobre la latencia del almacenamiento en Immich ofrece una prueba causal paralela: la contención de recursos compartidos solo importa cuando las esperas más largas del recurso coinciden con la acción del usuario que se retrasa. Aplica la misma disciplina a la red en lugar de suponer que todas las importaciones la saturan.

Este mecanismo deja de explicar una ralentización cuando la utilización de la WAN es moderada, el tiempo de ida y vuelta permanece estable y el propio servidor muestra un aumento de la latencia de las solicitudes o del almacenamiento. La contención de red y la del servidor pueden coexistir, así que identifica qué retraso cambia primero con una carga de trabajo controlada.

Prueba la importación como cuatro cronologías independientes

Utiliza un lote fijo que contenga muchas fotos pequeñas y varios vídeos grandes. Registra cuatro cronologías: la transferencia del cliente al servidor, la aceptación por parte del servidor, el procesamiento en segundo plano y la disponibilidad final para la búsqueda. Registra también la latencia de ida y vuelta, la velocidad de transferencia efectiva, los indicios de retransmisiones o reintentos y las métricas pertinentes de los recursos del servidor.

Compara el mismo lote mediante una Wi-Fi local o una LAN cableada y mediante la ruta remota prevista, sin cambiar la configuración del servidor. Usa las rutas directas frente a rutas con relé de Tailscale como referencia de transporte al interpretar un túnel. Si aumenta el tiempo de transferencia, pero el procesamiento del lado del servidor sigue siendo similar, la red es la variable determinante.

Acepta el diagnóstico de red solo cuando un cambio controlado de ruta mejore la etapa prevista mientras las demás etapas sigan siendo comparables. Esa evidencia es más sólida que una prueba de velocidad, un único ping alto o una afirmación general de que las cargas remotas siempre son más lentas.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.