Quantos utilizadores simultâneos consegue o Immich suportar antes de ficar mais lento?

Não existe um número universal útil de utilizadores simultâneos do Immich que todos os servidores domésticos consigam suportar, porque “um utilizador” pode significar navegação inativa, pesquisa por rostos, um carregamento grande, reprodução de vídeo ou várias tarefas em segundo plano ao mesmo tempo.

A capacidade deve ser medida como a carga doméstica máxima e repetível que continua a cumprir os seus próprios critérios de tempo de resposta e de erros. Estabeleça uma linha de base em repouso, reproduza ações mistas realistas, aumente a simultaneidade em etapas controladas e observe o primeiro recurso a ficar saturado. Assim, obterá um intervalo de capacidade defensável para o seu hardware e biblioteca, em vez de um limite de utilizadores inventado.

Defina o Que Significa “Ficar Mais Lento” Antes de Contar os Utilizadores

Escolha um pequeno conjunto de ações visíveis para os utilizadores que sejam importantes em sua casa: abrir a linha temporal, carregar um álbum antigo, pesquisar, reproduzir vídeos e carregar um lote. Antes do teste, defina o que será considerado uma falha, como latência inaceitável, tempos limite excedidos, carregamentos falhados, interrupções na reprodução ou uma fila que continua a crescer depois de os utilizadores pararem.

Não misture trabalho em primeiro plano e em segundo plano sem o registar. A geração de miniaturas, a transcodificação de vídeo, o processamento de rostos, a Pesquisa Inteligente, as análises da biblioteca, a manutenção da base de dados e as cópias de segurança podem consumir os mesmos recursos de CPU, memória, disco e rede que os utilizadores ativos. Um teste com “quatro utilizadores” durante uma grande importação representa uma carga diferente de quatro pessoas a navegar numa biblioteca estabilizada.

Registe o hardware, a versão do Immich, a localização da base de dados, o tipo de armazenamento, a ligação de rede, o tamanho da biblioteca e as tarefas ativas em segundo plano em cada resultado. Sem esse contexto, um número de utilizadores simultâneos não pode ser comparado de forma significativa depois de uma atualização ou com outro servidor doméstico.

Meça uma Linha de Base de Um Utilizador com o Trabalho em Segundo Plano Sob Controlo

Comece quando o sistema estiver num estado conhecido e meça um percurso representativo de um utilizador. Registe o tempo de resposta no cliente juntamente com a utilização da CPU, a pressão sobre a memória, a latência ou utilização do disco, o débito da rede, a atividade da base de dados e quaisquer filas de tarefas do Immich que consiga observar.

Uma declaração de capacidade só é significativa quando a carga, a duração do teste e os critérios de sucesso estão explícitos. Utilize testes de capacidade baseados na carga para guardar uma linha de base de um utilizador e, em seguida, meça como a latência, o débito e os erros variam à medida que a simultaneidade aumenta.

Se um utilizador já estiver a enfrentar lentidão, pare o teste de simultaneidade. Resolva primeiro o estrangulamento de um único utilizador; adicionar mais sessões apenas amplifica um problema existente de armazenamento, base de dados, CPU, rede ou configuração e diz pouco sobre o verdadeiro comportamento de escalabilidade do servidor.

Aumente a Simultaneidade Realista em Etapas Controladas

Adicione utilizadores ou sessões de cliente automatizadas gradualmente, mantendo a combinação de ações semelhante entre cada etapa. Uma sequência doméstica útil poderá duplicar as sessões ativas a partir de uma linha de base reduzida, mas os números exatos são menos importantes do que alterar apenas a simultaneidade e manter constante a definição da carga.

Defina os limites de latência, erros e débito antes dos testes e utilize percursos realistas com várias etapas, em vez de sobrecarregar um único endpoint. Uma carga de testes realista para o Immich deve combinar as ações que a sua família realmente executa, em vez de tratar pedidos de início de sessão repetidos como um substituto da capacidade de um servidor de fotografias.

Mantenha cada etapa durante tempo suficiente para que as caches, as filas, as ligações à base de dados e a procura de armazenamento estabilizem. Registe tanto o pico como a recuperação do sistema depois de a carga ser removida. Um servidor que parece aceitável durante um pico curto, mas deixa uma fila de tarefas crescente, já ultrapassou um nível sustentável para essa carga.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Identifique o Primeiro Recurso a Ficar Saturado

Quando a latência aumenta subitamente, correlacione o momento com o comportamento dos recursos. A saturação da CPU durante pesquisas ou aprendizagem automática sugere pressão computacional; uma latência elevada do disco com uma utilização moderada da CPU aponta para a base de dados ou para o armazenamento de conteúdos multimédia; ligações de rede totalmente ocupadas apontam para limites de transferência ou de acesso remoto; o aumento das esperas na base de dados ou a pressão sobre as ligações apontam para a camada de dados.

As tarefas em segundo plano podem alterar o resultado, porque a criação de miniaturas, a transcodificação, a aprendizagem automática, as análises, as cópias de segurança ou os ciclos de novas tentativas podem consumir recursos mesmo quando ninguém está a navegar ativamente. Compare o teste com as condições de carga em segundo plano do Immich controladas, para não confundir trabalho agendado com um limite reduzido de utilizadores.

Não “resolva” a capacidade ocultando os erros com tempos limite mais longos no cliente. Altere o recurso limitador ou a política de carga — por exemplo, agendando tarefas pesadas, melhorando a localização do armazenamento, reduzindo as transcodificações simultâneas ou adicionando capacidade de computação — e depois repita exatamente a etapa que falhou para provar que o estrangulamento mudou ou desapareceu.

Defina um Intervalo Prático de Capacidade Doméstica e Volte a Testá-lo

Defina a capacidade prática como a simultaneidade máxima testada em que todos os percursos de utilizador necessários permanecem dentro dos limites de latência e erros definidos antecipadamente, as filas regressam para perto da linha de base após o teste e o anfitrião conserva margem suficiente para o trabalho normal em segundo plano. Apresente-a como um intervalo específico da carga, não como um máximo geral do Immich.

Repita a etapa-limite pelo menos uma vez a partir de um estado limpo e comparável, incluindo as ações que anteriormente causaram degradação. Em seguida, teste brevemente a etapa seguinte, com mais carga, apenas o suficiente para confirmar que o limite continua a surgir no mesmo recurso, sem conduzir o sistema a uma fila descontrolada ou a um evento de pressão sobre o armazenamento.

Repita o mesmo teste depois de atualizações importantes do Immich, alterações da base de dados, mudanças de armazenamento ou hardware, ou de um aumento significativo do tamanho da biblioteca. O seu número de capacidade é uma propriedade do sistema e da carga atuais; conservar a receita do teste é mais valioso do que conservar uma contagem antiga de utilizadores.