Essa é uma boa especificação! Você deve ter um site particularmente movimentado?
Tem certeza de que não houve nenhum rebake ocorrendo?
Quantas imagens estão sendo postadas por minuto?
A preparação de miniaturas é, em sua maioria, código principal e requer processamento adicional obrigatório de imagens.
Este seria o caso de qualquer plugin ou componente de tema dessa natureza.
Desativamos o plugin por cerca de 24 horas, depois o reativamos por 24 horas.
Abaixo estou colando anotações do nosso outro administrador.
O plugin está causando lentidão no agendamento de trabalhos.
Quanto mais trabalhos na fila, mais a CPU luta para acompanhar.
Então, o que acontece é que o servidor vê muito tráfego, mas as coisas parecem normais por um tempo até que os trabalhos comecem a se acumular.
Eventualmente, a CPU luta para acompanhar e o uso aumenta e diminui à medida que conclui os trabalhos em atraso.
É por isso que vimos anteriormente que havia mais de 3000 trabalhos em atraso.
Em circunstâncias normais, nunca há mais de 5 trabalhos. mas quase sempre há 0 porque nenhum trabalho deve ficar em atraso, eles devem ser processados imediatamente.
A imagem anexada mostra os trabalhos atuais ficando em atraso. No momento, está pairando em 30-35 trabalhos em atraso.
Todos os trabalhos são novos da última postagem no sidecar.
Ainda não consigo dizer o porquê, mas isso só acontece quando o plugin está ativado.
Última hora dos recursos na CPU
últimas 24 horas, apontando aproximadamente onde o plugin foi ativado (Veja a tendência de alta após o pico)
Parece que o padrão é mais longo que 24 horas para notar, mas o plugin causa uso geral de recursos na faixa de 80-90+% na maior parte do tempo.
Assim que o desativarmos, começaremos a notar que nas próximas 24 horas o servidor terá uma média de 60-75% e os trabalhos não ficarão em atraso.
Também quando quisermos, alterei o app.yml para ter 16 workers do unicorn. quando quisermos reconstruir, acho que devemos desativar o plugin e ter 16 workers do unicorn. Observamos o desempenho do servidor durante esse período e ajustamos o valor dos workers para o que acharmos melhor.
Nos últimos 7 dias
vermelho = ativado
azul = desativado
Após reativar o plugin, a CPU está com picos. Tenho menos confiança de que a parte dos trabalhos seja um grande problema. Notei que a contagem de trabalhos aumenta com mais workers do unicorn. Acho que o número não está relacionado.
Ainda vejo o problema sobre o plugin segurando recursos.
Ainda não tenho 100% de certeza, mas estou muito confiante de que o plugin é um problema.
plugin + 16 workers: trava o servidor
16 workers sem plugin - funcionando bem
plugin + 8 workers - lento, mas funciona
gráfico após desativar o plugin
Olá,
Eu sou o outro administrador que fez essas anotações.
Não vejo mais os trabalhos como parte do problema.
Infelizmente, não tenho muito conhecimento sobre o funcionamento interno do Discourse para saber qual poderia ser a causa. Eu apenas sei o que vejo atualmente.
Pode ser resumido como o site está geralmente lento quando ativado com 8 workers e quase cai com 16 workers.
Com o plugin desativado, o site funciona perfeitamente e com workers suficientes, é muito rápido.
Isso me leva a acreditar que há algo com o plugin que está deixando o site lento, seja por recursos ou por algo que está sendo retido em operações de IO ou assíncronas, talvez.
Por favor, verifique sua fila do sidekiq. Você vê muitos trabalhos enfileirados e quais são os nomes dos trabalhos?
Tenho certeza de que é apenas um acúmulo de produção de miniaturas que diminuirá assim que todas as imagens forem processadas.
Esse é um processo principal.
Você pode remover com segurança o plugin sidecar se não precisar de seus recursos adicionais e usar apenas o Componente de Tema.
Você pode confirmar se o problema persiste com o Componente de Tema ativo, mas não com o plugin sidecar?
Se você nunca teve o plugin sidecar instalado, o problema deve estar no núcleo.
Se precisar de ajuda com sua análise, você pode contratar a Pavilion.
Agradeço relatórios independentes sobre este problema.
Apenas confirmando: um aumento nos trabalhos de redimensionamento de imagens com uso intensivo de CPU é esperado quando você habilita qualquer tipo de componente de tema de miniaturas de lista de tópicos 
. O Core gera as miniaturas ‘sob demanda’ para o primeiro usuário a visualizar um determinado tópico em uma lista de tópicos.
Como @merefield mencionou, deve se normalizar assim que todas as miniaturas forem geradas para os tópicos listados com frequência.
Aumentar o número de workers provavelmente não é uma boa ideia - tentar fazer mais trabalho em paralelo em uma máquina com restrição de CPU piorará os sintomas. É melhor manter o número de workers normal para que os trabalhos possam ser enfileirados e processados sem sobrecarregar a máquina.
Na interface do Sidekiq, você provavelmente vai querer olhar as abas “Busy” e “Queued”. Os trabalhos “Scheduled” são aqueles agendados para um horário específico no futuro, e, portanto, é muito improvável que estejam causando problemas de desempenho.
Parece ótimo na pré-visualização, mas na realidade é completamente diferente. O que estou fazendo de errado?
Muitos temas de “conversão total” não são suportados. Suspeito que o FKB Pro tenha suas próprias substituições que entram em conflito com este componente. Receio não poder suportar este cenário.
Este Componente de Tema destina-se a ser usado como um bloco de construção dentro de um tema que não tenta cobrir todas as bases.
Se você quiser uma barra lateral direita com Pré-visualizações da Lista de Tópicos, tente Blocos da Barra Lateral Direita em combinação.
Há um pequeno problema de CSS/espaçamento entre o cabeçalho do tópico e o ícone de link em destaque.
Adicionada uma funcionalidade experimental:
Isso está funcionando muito bem agora, ainda atrás de uma configuração:
Isso é responsivo à largura, então só aparece no modo Tiles (masonry) quando a área da lista é larga o suficiente.
Demonstração aqui: https://www.starzen.space/
NB O preenchimento excessivo no canto inferior direito é um problema conhecido e necessário devido ao renderizador de alvenaria que, por razões de desempenho (é rápido!), renderiza as coisas na linha de grade mais próxima. Assim que (!) eles implementarem a alvenaria nativa em CSS grid, refatorarei isso para torná-lo mais agradável.
NB#2 A captura de tela também contém alguns controles do componente temático Discourse Bars (a barra lateral está oculta). Topic List Previews funciona muito bem com Discourse Bars.
Uma imagem para o YouTube aparece na página inicial.
Poderia ser para o Twitter também?
Não é restrito ao YouTube de forma alguma.
Ele expõe o que quer que seja a miniatura. Se o embed do Twitter criar uma miniatura, então sim.
Você poderia me dizer quais configurações devo escolher para que fique como nesta imagem?
Eu quero que seja na forma de uma lista de miniaturas como nesta imagem.
imagem alinhada à esquerda
Remova rotas desta configuração:
Caso contrário, elas serão exibidas como “Tiles”. Se você quiser zero rotas no formato “Tiles”, remova todas essas linhas, mas talvez você queira considerar Tiles no celular (nesse caso, mantenha as com *-mobile).
Está perfeito agora, obrigado por isso 
Há uma configuração no plugin sidecar que o acompanha (listado no OP):
Mas sem o plugin, você pode querer tentar as configurações nativas:
Não olho isso há um tempo! 
Estou mexendo nas configurações que você mencionou, mas não funciona.
Curiosamente, há pouquíssimos resumos sobre um tópico e muitos sobre o outro.
O caractere deve estar dentro de um certo limite de caracteres.
Instale o plugin sidecar, use essa configuração.
Eu presumiria que você tem que disparar um “post rebake” para refazer o resumo do tópico.
