Como Acelerar a Entrega da Federação do Mastodon para Servidores Remotos Lentos

O Mastodon depende da federação para entregar postagens, curtidas e impulsionamentos a servidores remotos. Quando um servidor remoto está lento ou sobrecarregado, suas postagens podem levar minutos ou até horas para aparecer lá. Esse atraso ocorre porque o Mastodon enfileira as entregas de saída e as tenta novamente com temporizadores de backoff. Este artigo explica como ajustar as configurações do lado do servidor e usar ferramentas como o Sidekiq para reduzir a latência de entrega para servidores remotos lentos.

Você aprenderá quais arquivos de configuração controlam os timeouts de federação e os intervalos de repetição. Você também verá como monitorar a profundidade da fila e priorizar entregas para domínios específicos. Essas alterações exigem acesso à linha de comando do seu servidor Mastodon e uma reinicialização dos serviços principais.

Ao final deste guia, você será capaz de reduzir atrasos de entrega para postagens enviadas a instâncias remotas lentas sem afetar a estabilidade do seu servidor.

Por que a Entrega da Federação Fica Lenta em Servidores Remotos

O Mastodon usa um modelo de federação baseado em push. Quando você publica uma postagem, seu servidor envia requisições HTTP para cada servidor remoto que segue as contas ou hashtags mencionadas. Essas requisições são tratadas por workers do Sidekiq na fila push. Cada worker abre uma conexão, envia o payload da atividade e aguarda uma resposta.

Se um servidor remoto está lento, o worker mantém a conexão aberta até que ocorra um timeout. O timeout padrão do Mastodon para entrega ativa é de 10 segundos. Após uma falha, o trabalho é repetido com backoff exponencial começando em 30 segundos. Esse backoff pode crescer para horas em servidores persistentemente lentos. Se muitos servidores remotos estão lentos, a fila push enche, atrasando a entrega para todos os servidores, incluindo os rápidos.

A causa raiz é a combinação de concorrência limitada de workers e timeouts longos. Por padrão, o Mastodon executa 5 workers do Sidekiq para a fila push. Se dois workers estão presos esperando por servidores lentos, apenas três restam para lidar com todas as outras entregas. Aumentar a concorrência e reduzir os timeouts libera workers mais rapidamente, reduzindo a latência geral da fila.

Valores Padrão de Timeout e Repetição da Federação

Estes são os valores padrão no Mastodon 4.x que afetam a velocidade de entrega:

• FEDERATION_ACTIVE_TIMEOUT_SEC: 10 segundos – tempo de espera por uma resposta do servidor remoto antes de falhar a tentativa.
• FEDERATION_ACTIVE_RETRY_DELAY_MIN: 30 segundos – atraso mínimo antes de tentar novamente após uma falha.
• FEDERATION_ACTIVE_RETRY_DELAY_MAX: 1 dia (86400 segundos) – atraso máximo para falhas repetidas.

Passos para Acelerar a Entrega da Federação

Estes passos assumem que você tem acesso root ou sudo ao seu servidor Mastodon e pode editar arquivos de ambiente. Sempre faça backup do seu arquivo .env.production antes de fazer alterações.

1. Abra o arquivo de configuração de ambiente do Mastodon
   Execute sudo nano /home/mastodon/live/.env.production ou o caminho onde sua instância do Mastodon armazena as variáveis de ambiente. Se você usa um método de implantação diferente, localize o arquivo equivalente.
2. Aumente a concorrência do Sidekiq para a fila push
   Adicione ou modifique a linha SIDEKIQ_CONCURRENCY=10. Este valor define o número de threads de worker para todas as filas. O Mastodon usa arquivos de fila separados, mas a fila push se beneficia de maior concorrência. Comece com 10 e monitore o uso de memória. Cada worker usa cerca de 200 MB de RAM. Não exceda a memória disponível.
3. Reduza o timeout de entrega ativa
   Adicione FEDERATION_ACTIVE_TIMEOUT_SEC=5. Isso reduz o tempo que um worker espera por um servidor lento de 10 segundos para 5 segundos. Os workers falharão mais rápido e passarão para o próximo trabalho mais cedo.
4. Reduza o atraso mínimo de repetição
   Adicione FEDERATION_ACTIVE_RETRY_DELAY_MIN=15. Isso reduz o backoff inicial de 30 segundos para 15 segundos. Combinado com o timeout menor, as entregas com falha tentam novamente com o dobro da frequência.
5. Salve o arquivo e reinicie os serviços do Mastodon
   Execute sudo systemctl restart mastodon-sidekiq e sudo systemctl restart mastodon-web. As alterações entram em vigor imediatamente após a reinicialização.
6. Monitore a profundidade da fila push
   Execute sudo -u mastodon bash -c "cd /home/mastodon/live && bundle exec sidekiqmon". Observe o tamanho da fila push. Uma fila saudável deve ficar abaixo de 100. Se crescer acima de 500, aumente ainda mais a concorrência ou identifique o servidor lento.

Identificar e Limitar um Servidor Remoto Lento Específico

Se um servidor remoto causa acúmulo consistente na fila, você pode limitar quantas entregas simultâneas seu servidor envia para ele. O Mastodon não fornece uma interface gráfica para isso. Você deve usar a API do Mastodon ou um script personalizado. O método a seguir usa a API de administração do Mastodon para definir um limite de entrega por domínio.

1. Encontre o domínio do servidor lento
   Execute sudo journalctl -u mastodon-sidekiq -n 200 | grep "push" | grep -oP 'https?://\K[^/]+' | sort | uniq -c | sort -nr. Isso mostra os domínios remotos que aparecem com mais frequência em erros de entrega push.
2. Defina um limite de entrega usando a API do Mastodon
   Execute curl -X PATCH -H "Authorization: Bearer SEU_TOKEN_ADMIN" -d "domain=exemplo.lento.com&delivery_limit=1" https://sua.instancia/api/v1/admin/domain_blocks. Substitua SEU_TOKEN_ADMIN por um token de acesso de administrador e exemplo.lento.com pelo domínio real. Definir delivery_limit=1 permite apenas um push simultâneo para esse domínio, impedindo que ele monopolize os workers.

Se o Mastodon Ainda Tiver Atrasos de Entrega Após o Ajuste

Fila Push Continua Acumulando Após Aumentar a Concorrência

Se a fila permanecer acima de 500 após aumentar a concorrência para 10, verifique a CPU e a memória do seu servidor. Execute htop para ver se os workers do Sidekiq estão limitados pela CPU. Se o uso da CPU estiver próximo de 100%, o gargalo não é o servidor remoto, mas o processamento do seu próprio servidor. Nesse caso, atualize o hardware do servidor ou reduza o número de conexões simultâneas com servidores remotos diminuindo ainda mais FEDERATION_ACTIVE_TIMEOUT_SEC para 3 segundos.

Postagens Ainda Não Aparecem em Servidores Remotos

Se a entrega for bem-sucedida rapidamente, mas os servidores remotos ainda não exibirem suas postagens, o problema está no lado remoto. O servidor remoto pode ter seus próprios atrasos de processamento ou pode não ter recebido a postagem devido a problemas de rede. Use o endpoint de depuração do Mastodon: https://sua.instancia/api/v1/statuses/ID_DA_SUA_POSTAGEM/card para ver se o servidor remoto buscou a postagem. Se o card estiver vazio, o servidor remoto não processou a entrega. Entre em contato com o administrador remoto para verificar as filas do Sidekiq dele.

Memória do Redis Cresce Após Alterações de Configuração

Aumentar a concorrência pode fazer com que o uso de memória do Redis aumente, pois mais trabalhos são armazenados em memória. Monitore o Redis com redis-cli info memory. Se a memória exceder 70% da RAM do seu sistema, reduza SIDEKIQ_CONCURRENCY em 2 e reinicie o Sidekiq. Também defina uma política de maxmemory do Redis: redis-cli config set maxmemory-policy allkeys-lru.

Item	Valor Padrão	Valor Ajustado
Concorrência do Sidekiq	5	10
Timeout de entrega ativa	10 segundos	5 segundos
Atraso mínimo de repetição	30 segundos	15 segundos
Atraso máximo de repetição	1 dia	1 dia (inalterado)

Agora você pode reduzir atrasos de entrega da federação para servidores remotos lentos ajustando a concorrência do Sidekiq e os timeouts de entrega. Comece com os valores na tabela de comparação e ajuste com base nos recursos do seu servidor. Use sidekiqmon para monitorar a profundidade da fila push após cada alteração. Se um servidor remoto específico causar problemas persistentes, aplique um limite de entrega usando a API de administração. Essas configurações fornecem controle direto sobre a velocidade da federação sem modificar o código-fonte do Mastodon.