Porque é que o Immich parece menos responsivo em diferentes clientes?

O Immich pode parecer mais lento num cliente porque a renderização no cliente, a descodificação de imagens, o estado da cache e o percurso da rede acrescentam trabalho depois de o servidor responder.

Uma família pode consultar a mesma biblioteca num navegador de computador, num telemóvel antigo e num tablet, enquanto o servidor Immich, o armazenamento e a base de dados permanecem inalterados. Ainda assim, um dispositivo pode abrir as linhas cronológicas ou as pré-visualizações mais tarde, porque o pedido de ponta a ponta inclui trabalho fora do servidor. A comparação útil é, portanto, entre o tempo de resposta do servidor e o tempo adicional que cada cliente demora a receber, descodificar, colocar em cache e desenhar o resultado.

O cliente altera o trabalho realizado depois de o Immich responder

Um pedido do Immich não termina quando o servidor prepara JSON, um URL de miniatura ou uma resposta de imagem. O cliente ainda tem de processar essa resposta, atualizar a interface, agendar a renderização e reagir à interação do utilizador. Assim, um servidor rápido pode coexistir com um cliente que parece lento quando o dispositivo ou o navegador demora mais tempo a transformar os dados devolvidos num ecrã visível e interativo.

Esta distinção é especialmente importante nos navegadores, onde o JavaScript, o processamento de eventos, o cálculo de estilos, o esquema da página e grande parte da pintura competem pelo trabalho do thread principal. Se um telemóvel antigo ou um navegador ocupado mantiver esse thread ocupado durante mais tempo, os toques e o deslocamento podem sofrer atrasos, mesmo que a API do Immich tenha concluído aproximadamente ao mesmo tempo que num computador mais rápido.

É por isso que comparar apenas a CPU do servidor ou a latência da base de dados deixa de fora parte da experiência. A discussão da ZimaSpace sobre clientes nativos e de navegador demonstra o mesmo princípio dos sistemas: um backend pode alimentar diferentes percursos de execução no cliente. No Immich, a primeira questão de diagnóstico é saber se o atraso ocorre antes de a resposta chegar ou depois de o cliente começar a processá-la.

A renderização de imagens pode fazer com que respostas rápidas pareçam lentas

A consulta de fotografias torna a diferença entre clientes mais evidente, porque uma galeria não é apenas texto e metadados da API. Um cliente pode pedir muitas miniaturas ou uma pré-visualização maior, manter algumas em memória, descodificar dados de imagem comprimidos, redimensioná-los para a área visível e compor várias imagens enquanto o utilizador continua a deslocar-se. A quantidade e o momento desse trabalho local podem variar bastante entre dispositivos, mesmo quando pedem o mesmo recurso do Immich.

Os formatos comprimidos, como JPEG e WebP, têm de passar pela descodificação de imagens antes de os píxeis poderem ser apresentados. CPUs mais rápidas, descodificadores melhor otimizados, mais memória disponível e diferentes motores de navegador podem encurtar essa etapa. Num cliente mais fraco, a rede pode terminar primeiro, enquanto a descodificação e a pintura passam a ser a parte pela qual o utilizador realmente espera.

A consequência prática é que uma pré-visualização maior ou mais nítida não é gratuita apenas porque o servidor a consegue gerar rapidamente. Imagens de maior resolução exigem mais memória para os píxeis descodificados e mais trabalho para redimensionar e desenhar. Se um cliente ficar lento sobretudo ao abrir pré-visualizações completas ou ao deslocar-se rapidamente por linhas cronológicas densas, mas os ecrãs com metadados simples permanecerem responsivos, o percurso de renderização das imagens é uma explicação mais provável do que uma limitação geral de capacidade do servidor.

O estado da cache aquecida altera a velocidade das visitas repetidas

Um cliente que já tenha consultado um álbum pode reutilizar miniaturas, scripts, metadados ou recursos descodificados que um cliente novo ainda precisa de obter e processar. Isso torna a segunda passagem mais curta, mas não significa que o servidor tenha subitamente ganho capacidade. Significa que parte do percurso do pedido desapareceu, porque o cliente começou num estado mais aquecido do que na primeira passagem.

Estudos reais sobre navegadores mostram que as taxas de acerto da cache variam entre navegadores, versões, dispositivos e momentos diferentes. As percentagens específicas do Facebook não constituem uma referência de desempenho do Immich, mas o mecanismo é relevante: dois clientes podem chegar ao mesmo servidor com históricos de cache locais diferentes. Assim, um navegador de computador com a cache aquecida pode parecer muito mais responsivo do que uma aplicação de telemóvel recém-instalada, sem provar que algum dos clientes é inerentemente mais rápido.

A cache também cria testes enganadores de antes e depois. Atualizar o mesmo álbum várias vezes pode eliminar trabalho de transferência e processamento nas execuções posteriores, pelo que a execução mais rápida mede frequentemente a reutilização, e não uma carga familiar representativa. Se o objetivo for comparar clientes, registe tanto um percurso a frio ou recém-aberto como um percurso repetido; a diferença entre ambos constitui, por si só, uma indicação útil da dependência de cada cliente da reutilização local.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quando as diferenças entre clientes deixam de explicar o atraso

As diferenças entre clientes deixam de ser a explicação principal quando vários clientes diferentes ficam mais lentos ao mesmo tempo sob a mesma carga de trabalho. Se um navegador de computador, um telemóvel e um tablet esperarem todos mais tempo pelos dados da linha cronológica ou pelas respostas das pré-visualizações, enquanto a CPU do servidor, a latência do armazenamento, a atividade da base de dados ou a utilização da rede aumentam, a infraestrutura partilhada torna-se uma causa mais plausível da capacidade de resposta do que qualquer implementação de cliente específica.

A medição de ponta a ponta deve incluir mais do que o componente que parece mais fácil de medir. Uma análise de latência da Datadog demonstra que a latência de ida e volta pode incluir a transferência pela rede, proxies, conjuntos de ligações e descodificação da aplicação fora da própria base de dados. O mesmo princípio aplica-se ao Immich: um valor saudável da base de dados não permite excluir atrasos noutro ponto entre o início do pedido e o resultado renderizado.

Um teste de fronteira útil é a simetria. Se apenas um cliente estiver lento enquanto outro, na mesma LAN e com o mesmo álbum, permanecer rápido, a execução do cliente, a cache ou a rede local merecem mais atenção. Se todos os clientes ultrapassarem aproximadamente o mesmo limiar de latência ao mesmo tempo, especialmente durante importações, geração de miniaturas, cópias de segurança ou outra atividade do anfitrião, a explicação mudou da variação entre clientes para uma limitação partilhada do servidor, do armazenamento ou da rede.

Utilize um teste controlado entre clientes para encontrar a fronteira

Escolha um álbum representativo e mantenha constantes a versão do servidor, a localização na rede, a conta, o conjunto de imagens e o estado dos trabalhos em segundo plano. Teste cada cliente individualmente e registe três tempos observáveis: o carregamento inicial da linha cronológica, a abertura da mesma pré-visualização grande e um deslocamento rápido por um intervalo fixo de fotografias. Registe também se o servidor apresenta um pico de recursos durante cada execução, porque uma comparação entre clientes é inválida se a carga do backend mudar entre amostras.

Execute cada cliente uma vez a partir de um estado deliberadamente frio e novamente logo a seguir. Os testes de desempenho separam frequentemente os resultados da primeira visualização e da visualização repetida, porque as caches preenchidas eliminam trabalho dos pedidos posteriores. No Immich, a diferença entre frio e aquecido indica quanto a reutilização altera a experiência, enquanto a diferença entre clientes sob a mesma condição de cache revela diferenças mais provavelmente locais ao dispositivo ou à aplicação.

Considere uma diferença como específica do cliente apenas quando se repetir em pelo menos três execuções e o cliente mais rápido continuar a sê-lo, mantendo condições comparáveis no servidor e na rede. Se todos os clientes piorarem em conjunto, deixe de ajustar o cliente e examine o percurso comum. Se apenas as ações com muitas imagens divergirem, concentre-se na descodificação e na renderização. Se a diferença surgir apenas na primeira execução, o estado da cache — e não a capacidade sustentável do servidor — é a conclusão mais defensável.