Como medir o desempenho do Immich sem confundir a cache com a capacidade

A capacidade do Immich deve ser medida com cargas de trabalho a frio, em aquecimento e sustentadas repetidas, porque uma única execução rápida, servida pela cache, pode ocultar o verdadeiro ponto de saturação do sistema.

Um servidor doméstico pode fazer com que uma linha temporal ou um álbum pareça extremamente rápido depois de as mesmas miniaturas, páginas da base de dados e dados da aplicação já terem sido acedidos. Esse resultado prova que o percurso em cache é eficiente, não que o sistema consegue suportar uma biblioteca familiar maior ou mais atividade simultânea. Um teste de capacidade útil deve controlar o estado da cache, aumentar o conjunto de trabalho, repetir as execuções e definir uma condição de paragem mensurável.

Velocidade da Cache Não É o Mesmo que Capacidade

A capacidade descreve quanto trabalho representativo um sistema Immich consegue sustentar antes de a latência, as filas ou os erros se tornarem inaceitáveis. A velocidade da cache responde a uma pergunta mais restrita: com que rapidez consegue o sistema repetir trabalho depois de os dados úteis ou os recursos gerados já estarem próximos? Se um teste repetir o mesmo álbum ou a mesma linha temporal, estas duas perguntas podem parecer idênticas, embora estejam a medir condições operacionais diferentes.

A diferença é fácil de observar no desempenho web, onde os tempos da primeira visualização e das visualizações repetidas podem divergir porque os pedidos posteriores reutilizam recursos em cache. O Immich tem oportunidades adicionais para um comportamento em aquecimento, porque as miniaturas, as pré-visualizações, as páginas da base de dados, os metadados do sistema de ficheiros, a cache do sistema operativo e os recursos do cliente podem ser todos reutilizados. Uma execução repetida pode, por isso, eliminar trabalho que uma biblioteca em crescimento ou acedida pela primeira vez ainda teria de realizar.

É pela mesma razão que um teste do Home Assistant centrado na cache pode induzir em erro quando os pedidos repetidos dominam a amostra; a discussão da ZimaSpace sobre camadas de cache para pedidos repetidos aplica-se à lógica de medição aqui. No Immich, registe o desempenho em aquecimento, mas identifique-o como um percurso separado, em vez de o tratar como a capacidade geral do servidor.

Separe as Execuções a Frio, em Aquecimento e em Estado Estacionário

Comece por definir o estado antes de iniciar o cronómetro. Uma execução a frio deve incluir trabalho que não tenha acabado de ser repetido, como abrir um intervalo de datas ou um conjunto de recursos diferente depois de as caches terem tido menos oportunidades para ajudar. Uma execução em aquecimento repete deliberadamente um percurso conhecido. Uma execução em estado estacionário mantém uma atividade representativa durante tempo suficiente para revelar trabalho em segundo plano, reciclagem de recursos e filas que uma rajada curta poderá nunca mostrar.

O próprio aquecimento pode induzir em erro. A Percona descreve casos em que uma base de dados parece aquecida enquanto processos em segundo plano atrasados continuam a alterar o desempenho, pelo que o estado estacionário chega mais tarde do que as primeiras consultas rápidas. O Immich pode, de forma semelhante, sobrepor a navegação em primeiro plano à atividade da base de dados, ao processamento de miniaturas, à indexação ou a outras tarefas em fila, dependendo do que a biblioteca estiver a fazer nesse momento.

Para um teste num servidor doméstico, execute cada fase separadamente em vez de as juntar numa média. Registe se as tarefas em segundo plano estão inativas ou ativas, mantenha constantes o cliente e o percurso de rede e repita várias vezes a mesma fase. Se a execução em aquecimento for rápida, mas a atividade sustentada aumentar gradualmente a latência ou a profundidade da fila, o segundo resultado é o melhor indicador para planear a capacidade.

Torne o Conjunto de Trabalho Maior do que a Cache Fácil

Um teste que abra as mesmas vinte fotografias é normalmente demasiado pequeno para responder a uma pergunta sobre a capacidade de uma biblioteca familiar. O sistema operativo, a base de dados, o cliente e a camada de armazenamento podem manter um pequeno conjunto frequente perto do processador, enquanto a utilização real alterna entre meses, pessoas, álbuns, resultados de pesquisa e vídeos. O conjunto de teste deve, por isso, ser suficientemente grande e variado para que nem todas as operações beneficiem dos mesmos dados acedidos recentemente.

As práticas de testes de bases de dados tornam a distinção explícita: quando um teste pretende analisar o armazenamento ou o comportamento a frio, a cache residual pode transformar o exercício num teste ao desempenho da cache. Não é necessário limpar todas as camadas de cache num servidor Immich de produção para obter informação útil, mas é necessário ter uma carga de trabalho cujo conjunto de trabalho seja mais amplo do que um único ecrã reutilizado repetidamente.

Escolha vários intervalos de datas, álbuns, pesquisas e tipos de recursos que se assemelhem à utilização normal de uma família e, em seguida, alterne entre eles em vez de insistir numa única vista. Mantenha essa definição da carga de trabalho nas comparações entre hardware ou configurações. Se uma alteração apenas melhorar um pequeno subconjunto repetido, enquanto a navegação mais ampla continua a degradar-se sob carga, melhorou o percurso frequente sem alterar o limite de capacidade útil.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Meça Percentis e Repita o Teste

Uma única média pode ocultar os momentos que os utilizadores realmente notam. Se nove pedidos forem rápidos e o décimo bloquear enquanto uma fila cresce ou o armazenamento está ocupado, a média pode continuar a parecer aceitável. Registe, no mínimo, o comportamento mediano e um percentil de cauda, como o p95, e associe a latência ao débito, à contagem de erros, ao volume de tarefas pendentes, à CPU, à pressão de memória e à atividade do armazenamento, para que a lentidão tenha contexto.

A análise prática de testes recomenda comunicar p50, p95, p99 e a variância, em vez de confiar numa única execução, especialmente em sistemas com estado, onde a expulsão da cache, a compactação ou a atividade em segundo plano podem surgir mais tarde. Os testes do Immich não precisam de precisão laboratorial, mas precisam de repetições suficientes para distinguir um limite reproduzível de um intervalo de sorte e pouca atividade.

Execute o mesmo cenário pelo menos várias vezes em cada nível de carga e guarde as observações brutas, em vez de conservar apenas o melhor resultado. Uma afirmação sobre capacidade torna-se mais credível quando o p95 permanece estável entre execuções e o servidor consegue esvaziar o trabalho em fila entre os intervalos. Se os resultados variarem muito, investigue a variável não controlada antes de declarar que mais utilizadores, mais fotografias ou hardware mais rápido alteraram o limite.

Use um Protocolo de Capacidade do Immich com uma Condição de Paragem

Comece com uma carga de trabalho representativa de um único cliente e registe uma linha de base depois de o sistema atingir o estado que pretende testar. Em seguida, aumente uma variável de cada vez: mais navegação simultânea, carregamentos, pesquisas ou processamento em segundo plano, mantendo fixa a biblioteca, a combinação de clientes, o percurso de rede e a configuração do servidor. Em cada passo, registe a latência p50 e p95, as operações bem-sucedidas por minuto, os erros, o crescimento da fila e o principal recurso do servidor que se aproxima da saturação.

Esta abordagem evita o erro comum de tirar conclusões de uma única execução curta. As orientações para testes de desempenho alertam contra conclusões baseadas numa única execução, porque o aquecimento, o estado da cache, o trabalho em segundo plano e o ruído normal do sistema podem dominar uma amostra. Repita cada nível de carga até que a tendência seja suficientemente estável para ser explicada, e não apenas suficientemente conveniente para ser citada.

Defina uma regra de paragem antes de testar. Uma heurística prática para um laboratório doméstico é considerar a configuração atual saturada quando a latência p95 permanece acima de aproximadamente o dobro da linha de base sem carga durante três intervalos de medição consecutivos, ou quando os erros ou a fila de tarefas continuam a crescer em vez de recuperarem; esta é uma heurística de teste, não um limite do Immich. O número de capacidade útil é o último nível de carga abaixo desse limite, medido com o mesmo protocolo a frio, em aquecimento e em estado estacionário.