O Plex não tem um limite universal de tarefas simultâneas; o Direct Play só se degrada quando o trabalho sobreposto consome a margem de recursos de que a entrega de conteúdos multimédia ainda necessita.
Uma análise da biblioteca, uma cópia de segurança, um indexador de fotografias, um cliente de transferências, uma máquina virtual ou uma transcodificação podem ser executados em simultâneo com o Plex, mas não têm todos o mesmo custo em termos de recursos. O limiar útil não é, portanto, um número de tarefas. É o primeiro ponto repetível em que uma sessão Direct Play conhecida perde margem no arranque, na procura ou no armazenamento em buffer enquanto a carga concorrente está ativa.
Defina o trabalho simultâneo pela exigência de recursos, não pelo número de tarefas
Comece por separar os trabalhos simultâneos pelos recursos que realmente consomem. Uma análise de metadados pode gerar leituras de ficheiros pequenos e trabalho na base de dados, uma cópia de segurança pode dominar a E/S sequencial e uma transcodificação de vídeo pode acrescentar uma exigência sustentada de processamento ou de acelerador. Chamar “uma tarefa” a cada um dos três oculta a parte do servidor com a qual competem.
O limite prático surge quando a procura atinge um recurso partilhado, e não quando existe um determinado número de processos. O tempo de CPU, a memória disponível, a E/S do armazenamento e o débito da rede têm, cada um, a sua própria capacidade, pelo que os limites de recursos precisam de sinais separados, em vez de uma única pontuação de utilização geral.
Descreva a carga de trabalho como uma combinação: uma sessão Direct Play, uma cópia de segurança, uma análise, dois contentores, e assim por diante. Essa descrição pode ser reproduzida mais tarde e mantém o teste ligado ao comportamento doméstico real, em vez de a uma contagem arbitrária de processos em segundo plano.
Mantenha o Direct Play constante antes de medir a margem disponível
Escolha um ficheiro e um cliente que já utilizem o Direct Play de forma fiável e, em seguida, mantenha inalterados o áudio, as legendas, a qualidade e o percurso de rede selecionados. Se a sessão mudar silenciosamente para uma transcodificação, o teste passou a avaliar outra tarefa e já não consegue indicar quanto trabalho simultâneo um percurso Direct Play tolera.
O Direct Play depende da compatibilidade do cliente e da capacidade de entrega, não apenas do processador do servidor. Uma linha de base estável deve, por isso, confirmar que o ficheiro original continua compatível e que a rede tem margem suficiente para o seu débito real antes de adicionar qualquer tarefa concorrente.
Registe o tempo de arranque, uma procura representativa, a reprodução contínua, o CPU e a memória do servidor, a latência do armazenamento e o débito da rede. Estes valores de referência permitem comparar a lentidão posterior, em vez de depender da impressão vaga de que o Plex “parecia pior”.
Adicione trabalho em segundo plano uma camada de cada vez
Introduza as tarefas reais que podem sobrepor-se à visualização, mas adicione-as uma de cada vez antes de testar combinações. Comece pela sobreposição mais comum, como uma tarefa agendada da biblioteca ou uma cópia de segurança, e repita o mesmo pedido de reprodução. Se a sessão continuar a passar no teste, adicione a tarefa realista seguinte, em vez de saltar diretamente para um máximo sintético.
Uma transmissão Direct Play é normalmente mais leve do que uma transcodificação, mas continua a precisar de armazenamento e de entrega pela rede. O 4K com elevado débito ilustra por que razão o Direct Play continua a consumir recursos reais, mesmo quando o servidor não volta a codificar o vídeo; por isso, a contenção do armazenamento ou da rede pode degradar a reprodução sem existir um estrangulamento no processamento.
Mantenha cada tarefa adicionada ativa durante tempo suficiente para atingir o seu estado normal de funcionamento estável. Uma cópia de segurança executada durante dez segundos ou uma análise que já tenha terminado não revelará a mesma contenção que a carga de trabalho que efetivamente se sobrepõe ao período de visualização noturno.
Observe qual é o primeiro recurso partilhado a perder margem
Trate a primeira alteração visível para o utilizador como um momento registado e compare os sinais dos recursos nesse intervalo. Um pico de CPU só é relevante se o trabalho de processamento também estiver a ficar para trás; uma utilização elevada da memória é importante quando a recuperação de memória ou a troca altera a latência; o armazenamento e a rede precisam de evidências de filas, latência ou débito, e não apenas de um gráfico com aspeto ocupado.
O conceito fundamental é a contenção por um recurso partilhado. Quando várias tarefas precisam simultaneamente do mesmo CPU, memória, disco ou percurso de rede, o tempo de resposta pode aumentar, mesmo que outras partes do servidor continuem a parecer inativas.
Pause a tarefa concorrente suspeita e repita o mesmo pedido de Direct Play. Se a reprodução regressar imediatamente à linha de base enquanto o sinal de pressão correspondente diminui, o limite de simultaneidade começa a ter suporte factual. Se nada mudar, restaure a carga de trabalho e teste o recurso partilhado seguinte, em vez de atualizar o equipamento por tentativa e erro.
Transforme o ponto de falha observado num limite de capacidade
Uma afirmação útil sobre a capacidade identifica a carga de trabalho e o recurso que falhou: por exemplo, uma transmissão Direct Play conhecida permanece estável com os contentores e a análise normais, mas a latência do armazenamento aumenta e a procura deixa de funcionar quando começa a cópia de segurança. Isto é mais aplicável ao seu servidor do que dizer que “o Plex suporta seis tarefas”.
Instalações Plex muito grandes mostram por que razão uma contagem de sessões apresentada como referência não constitui um limite universal. Uma instalação com 40–50 sessões simultâneas pode combinar transmissões diretas, transcodificações, capacidade de rede e escolhas de hardware completamente diferentes das de um pequeno servidor doméstico.
Mantenha uma margem de segurança abaixo da primeira falha repetível e volte a testar depois de alterações importantes na carga de trabalho. Se a questão se limitar especificamente a clientes mistos que devem permanecer em Direct Play, utilize o limite de Direct Play com clientes mistos para separar alterações de compatibilidade da saturação de recursos partilhados.
Centro de Tecnologia e IA
Mais para Ler

O que é o estado do Plex e que partes têm de persistir?
O estado persistente do Plex é a informação que preserva a experiência do servidor após reinícios e reconstruções; os dados multimédia e temporários de...

Como é que o Plex gere a autenticação entre sessões locais e remotas?
A autenticação do Plex começa pela identidade do servidor e da conta; depois, os caminhos de rede locais ou remotos determinam a acessibilidade e...

Porque é que a pesquisa no Plex pode ficar mais lenta à medida que os dados da biblioteca aumentam?
O crescimento da biblioteca, por si só, não é o diagnóstico. Teste a estrutura das consultas, os índices, o estado da cache, a latência...

