Temos 5 milhões de posts e a busca é bastante rápida. Estamos hospedados em 6 vcores compartilhados de um Xeon E5-2680 de 2,8 GHz, com 16 GB de RAM e armazenamento em SSD. Dito isso, não tenho métricas sobre quantos posts simultâneos nossos usuários iniciam; pode haver problemas de bloqueio.
Postar, por outro lado, costuma ser bastante lento. Pode levar de 6 a 7 segundos para um post ser processado. O Discourse é não bloqueante enquanto trabalha, o que não prejudica a experiência do usuário, embora.
Os tempos de postagem de 6 a 7 segundos são específicos para os tópicos mega? Se você responder a um tópico com 100 respostas, também leva de 6 a 7 segundos?
Não consegui reproduzir agora mesmo — a postagem lenta é intermitente. Não parece estar correlacionada com a quantidade de postagens no tópico. Talvez seja um problema de bloqueio com outra pessoa postando simultaneamente ou algo assim.
7 postagens = muito rápido, aproximadamente o mesmo que aqui no meta
500 postagens = talvez um pouco mais lento, nada muito ruim. Talvez 1,5 segundo?
16 mil postagens = parece ser mais ou menos o mesmo que com 500
E acredito que o desempenho também é afetado se um grupo de pessoas estiver acessando um tópico massivo, o que deixa o servidor PG inteiro mais lento com solicitações em fila.
Como você está se sentindo corajoso? Você se importa em ativar o mini_profiler por um tempo? Ele mostrará os tempos ao lado, e assim poderemos isolar qual consulta está apresentando problemas para você!
Qual é o impacto da ativação no desempenho geral? E é possível ativá-la sem reconstruir o site? Não consegui fazer uma reconstrução ser bem-sucedida desde a mudança para o PostgreSQL 12, mesmo configurando para permanecer no pg10.
Você precisa definir seu endereço de e-mail como o e-mail do desenvolvedor no arquivo app.yml. Você pode aplicá-lo sem reconstruir, destruindo e reiniciando o contêiner. Se você tiver feito alterações no contêiner ao atualizar com o Discourse Docker, elas serão perdidas.
Você também pode editar config/discourse.conf dentro do contêiner e, em seguida,
Considerando que as reconstruções estão falhando, minha preocupação é que, se eu destruir o container, ficarei completamente sem alternativas. Tive tantos erros ao tentar a atualização para o PostgreSQL 12 ontem que não me sinto confortável em fazer alterações até ter a certeza de que não derrubarei o site por um período prolongado.
Bem, conselhos gratuitos valem o que você pagou por eles, mas é bastante seguro executar:
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# no vi, edite a linha developer_emails para incluir seu endereço de e-mail e saia do vi
sv unicorn restart
# entre em pânico pelos 30 a 90 segundos que o servidor web leva para reiniciar e começar a servir páginas
No entanto, ainda é possível quebrar coisas dessa maneira. Acredito que seja possível estragar o arquivo de configuração de forma que o Discourse não inicie.
Ótimo! Qualquer melhoria substancial no tempo de postagem vai deixar nossos usuários muito felizes; essa é a coisa mais reclamada no momento. Embora eu não tenha dúvida de que eles logo encontrarão outra coisa para se queixar.
Se isso te deixar mais tranquilo, eu também reclamei dessa consulta, porque tenho muito estado de leitura aqui no meta. Estamos fazendo trabalho inútil para contar coisas em cada resposta…
Em nossa importação de teste de outro software, temos um tópico com pouco mais de 200.000 posts e consegui postar nele sem problemas. Deve ser porque não é o tamanho do tópico que importa, mas sim o usuário que está fazendo a postagem.
