A pesquisa do Jellyfin pode ficar mais lenta à medida que a biblioteca cresce, quando o processamento das consultas ou o conjunto de dados em utilização ultrapassa a capacidade dos índices eficientes e da reutilização da cache.
O crescimento, por si só, não prova que existe um problema na base de dados. Um catálogo maior pode alterar o número de registos, relações e pesquisas de imagens, enquanto as análises ou escritas em segundo plano acrescentam contenção. Mantenha a consulta e o cliente constantes e, em seguida, separe o tempo da base de dados do carregamento de imagens e da apresentação da interface.
O crescimento altera o trabalho da consulta
Uma biblioteca em crescimento acrescenta títulos, pessoas, géneros, caminhos, IDs de fornecedores e relações que a pesquisa pode analisar ou combinar. O custo depende da estrutura da consulta e da adequação dos índices, não apenas do número de bytes multimédia.
Use o modelo de funções dos dados persistentes para pensar em termos de registos e relações, em vez de um único número de “tamanho da biblioteca”.
Uma grande coleção de ficheiros de filmes pode continuar a responder rapidamente se o número de objetos indexados for moderado, enquanto muitos itens pequenos podem aumentar rapidamente o trabalho das consultas.
Os índices e a estrutura da consulta têm de corresponder
Um índice é útil quando a ordem das respetivas chaves e a seletividade correspondem aos filtros ou à ordenação utilizados. Uma consulta que procure texto amplo, combine várias relações ou ordene um resultado grande pode continuar a analisar mais dados do que uma pesquisa restrita.
Compare a consulta com uma explicação geral sobre latência e débito do armazenamento para compreender como diferem a latência do armazenamento e os padrões de acesso; o resultado exato no Jellyfin depende da base de dados e do percurso do cliente.
A medição útil é a mesma consulta antes e depois do crescimento, não um teste de desempenho baseado num padrão de pesquisa diferente.
A cache e o armazenamento podem parecer custos da consulta
Páginas frias da base de dados, ficheiros de imagens e metadados do sistema de ficheiros podem fazer com que a pesquisa pareça mais lenta, mesmo quando o plano da consulta não se alterou. As análises ou cópias de segurança em segundo plano podem acrescentar espera e expulsar páginas úteis entre execuções.
Separe os casos frios e quentes utilizando o método de teste de desempenho frio e quente antes de atribuir a causa ao crescimento do catálogo.
Se a segunda pesquisa for rápida, mas a primeira for lenta, a cache ou o armazenamento fazem parte da experiência. Se ambas forem lentas, o trabalho da consulta ou a contenção da base de dados merecem maior atenção.
Faça uma verificação de causa versus desvio
Meça o tempo da consulta, a apresentação dos resultados, o carregamento de imagens, a latência do armazenamento e as escritas em segundo plano como eventos separados. Em seguida, repita o teste depois de interromper temporariamente uma tarefa concorrente ou alterar uma variável do pedido.
Um breve fluxo de trabalho sobre o comportamento dos clientes do Jellyfin pode mostrar se o sintoma pertence ao trabalho da base de dados, ao percurso das imagens ou à interface do cliente.
Deixe de atribuir a lentidão ao crescimento da biblioteca quando a remoção de outra causa restabelecer o desempenho de referência. O crescimento é a condição; o mecanismo limitador ainda precisa de ser comprovado.
Centro de Tecnologia e IA
Mais para Ler

As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...

Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...

É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...

