Como fazer um benchmark do Immich com uma carga de trabalho repetível num servidor doméstico

Um benchmark reproduzível do Immich fixa o conjunto de ficheiros, o percurso do cliente, o estado da cache, a sobreposição de tarefas em segundo plano e o endpoint medido antes de alterar uma variável.

Sem esses controlos, uma segunda execução mais rápida pode refletir dados já em cache, e não hardware melhor, enquanto um teste em inatividade pode ocultar a contenção durante a importação. Um benchmark útil de um servidor doméstico reproduz as necessidades reais da família em termos de navegação, carregamento, pesquisa e recuperação, pela mesma sequência.

Defina os resultados para o utilizador antes de recolher métricas

Comece por resultados observáveis, como a aceitação do carregamento, o tempo até uma nova fotografia ficar pesquisável, a conclusão das miniaturas da cronologia, a abertura do original, o início de um vídeo ou a recuperação de uma biblioteca utilizável. A utilização do CPU e o débito do disco explicam estes resultados, mas não substituem o resultado visível para o utilizador.

O artigo da ZimaSpace sobre o percurso de dados do Immich separa a aceitação do carregamento, a disponibilidade do processamento, a seleção da pesquisa e a entrega dos conteúdos multimédia. Esta estrutura é útil porque um benchmark deve medir um endpoint, em vez de combinar várias fases dependentes num total enganador.

Selecione dois endpoints interativos e um endpoint em segundo plano. Defina um objetivo de aprovação para cada um e registe a mediana, além da latência da cauda lenta ou da taxa de conclusão. Um benchmark com muitos resultados sem relação entre si torna-se difícil de interpretar; um conjunto reduzido, associado a uma decisão específica, mantém os resultados acionáveis.

Fixe o conjunto de dados, o percurso do cliente e o estado inicial

Utilize as mesmas fotografias e vídeos representativos em todas as execuções, incluindo formatos e tamanhos que correspondam à biblioteca da família. Fixe a conta, o dispositivo cliente, o percurso de rede, a versão do Immich e as definições dos derivados. Até uma cache do navegador ou um percurso Wi-Fi alterado pode sobrepor-se à diferença de configuração que está a ser testada.

Um artigo sobre benchmarks de pesquisa vetorial salienta a importância de cargas de trabalho reproduzíveis de criação de embeddings, inserção e obtenção ao estudar o desempenho da pesquisa no PostgreSQL. O Immich é uma aplicação mais abrangente, mas o princípio experimental aplica-se igualmente: são necessários dados de entrada controlados e operações de obtenção definidas antes de as diferenças de tempo permitirem tirar conclusões.

Crie um manifesto do conjunto de dados que contenha somas de verificação dos ficheiros, contagens, totais de bytes, formatos das fotografias, durações dos vídeos e resultados de pesquisa esperados. Adicione uma lista de verificação inicial para serviços reiniciados, ações de aquecimento, tarefas em fila e aplicações concorrentes. Se a lista de verificação for diferente, marque a execução como não comparável, em vez de a incluir na média.

Execute fases a frio, aquecida e sustentada

A fase a frio revela o custo da inicialização e do primeiro acesso. A fase aquecida revela a reutilização durante repetições imediatas. A fase sustentada combina interações repetidas com uma importação representativa ou uma fila de tarefas em segundo plano durante tempo suficiente para expor redução térmica de desempenho, pressão de memória, filas de armazenamento e concorrência por recursos.

Um relato da comunidade descreve uma primeira pesquisa inteligente a demorar cerca de cinco segundos e uma repetição imediata cerca de meio segundo, enquanto a memória do modelo se altera. Esses valores não são um padrão de benchmark; demonstram por que motivo calcular a média de pedidos a frio e aquecidos oculta a transição que o teste precisa de explicar.

Execute cada fase pelo menos três vezes, preservando os carimbos de data e hora brutos e os rastreios de recursos. Mantenha a mediana e uma medida da cauda lenta para o trabalho interativo, além do número de itens processados por minuto para o trabalho em segundo plano. Interrompa a execução se erros, tempestades de swap ou limites térmicos invalidarem a condição estável pretendida.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilize uma folha de execução com uma variável

Escreva a hipótese antes da execução: alterar a localização da base de dados, a concorrência dos trabalhadores, o limite de memória, o percurso de rede ou o acelerador deverá melhorar um endpoint identificado através de um mecanismo especificado. Mantenha tudo o resto fixo. Isto evita que uma atualização com várias alterações produza um resultado mais rápido sem uma causa defensável.

Uma análise geral de estrangulamentos explica que os limites do CPU, da RAM, do armazenamento e da rede produzem padrões de utilização e efeitos diferentes para o utilizador. Aplicada ao Immich, a evolução das métricas de apoio deve ser coerente com a do endpoint; o gráfico mais ocupado não é automaticamente o componente limitador.

Registe os resultados de base e alterados para as fases a frio, aquecida e sustentada e, em seguida, marque-os como aprovados, reprovados ou inconclusivos. Rejeite melhorias que desapareçam após repetição ou que provoquem erros, temperaturas instáveis, perda do progresso da fila ou uma recuperação mais demorada. Preserve o manifesto e a folha de execução para que uma versão futura possa ser comparada de forma honesta.