This is now done via:
We no longer carry post ids in memory and the rebake task can be resumed by running posts:rebake_uncooked_posts.
One caveat here is that the resume task will not rebake posts in reverse order (i.e. the sort order will be id ascending).
So @techAPJ, if I need to trigger a rebake of every post on a Discourse install, is @pfaffman’s method the proper one to use?
If you need to rebake all posts instantly then run bundle exec rake posts:rebake.
Post.update_all("baked_version = NULL") will rebake 100 posts (by default) every 15 minutes.
Thanks, Arpit.
FYI, I encountered some performance issues with that approach, so I went with this, which alleviated the problem and resulted in the same outcome:
Post.in_batches.update_all('baked_version = NULL')
@techAPJ I have a dummy question. Where do you run this command? After entering the app?
It tells me
bash: syntax error near unexpected token ''baked_version = NULL''
./launcher enter app
rails c
Post.in_batches.update_all('baked_version = NULL')
Would the batch method be suitable for a large amount of rebakes?
2851000 / 27182220 ( 10.5%)
This our current process after starting it yesterday with the normal rebake command, it seems to tick about 1000 every 3 seconds. We are very close to the end of our import journey and testing, and I just wanted to make sure there was a more proper way to rebake a large site before we settled on this slower method.
Alguém pode explicar como esta versão do in_batches funciona. Presumivelmente, ele faz o re-bake em lotes, mas pelas postagens acima, é afirmado que, por padrão, ele faz o re-bake em lotes de 100 a cada 15 minutos por padrão.
Tenho um trabalho de 2 milhões de re-bakes para fazer e estou tentando descobrir a melhor maneira de fazer isso. O trabalho não tem urgência, mas quero ter certeza de que a operação normal e as operações administrativas (como backup) não sejam impactadas por um trabalho de longa duração.
E agora acabei de ler esta postagem: Rebaked all my posts, but what's it doing now? que me diz que a tarefa de re-bake nem está re-fazendo o bake delas, mas apenas marcando-as para re-bake (como essa marcação é feita?). O processo é tão lento que estou realmente lutando para acreditar que leva tanto tempo apenas para marcar uma postagem para re-bake.
Então migre para um servidor mais rápido.
Fique grato por isso não sobrecarregar seu site. O objetivo é impedir que esse processo consuma muitos recursos, mantendo seu site responsivo durante o processo.
Consultar o código-fonte é sempre uma boa ideia:
De fato, a marcação deve ser muito rápida. E o rebake_post parece fazer a chamada para o cozimento. Talvez existam algumas tarefas assíncronas que acontecem como parte disso ou como resultado disso?
Sim, claro, é um trabalho que gera um conjunto de trabalhos
Não é a solução ideal, mas encontrei outra maneira!
Eu escrevi meu próprio re-baker que é 1000x mais rápido, então em vez de levar um mês, leva apenas alguns minutos.
Na verdade, farei o re-bake pouco antes da inserção no banco de dados, para que o custo do re-bake desapareça no tempo de inserção do banco de dados.
ah, ok não estava ciente do seu contexto.
sim, isso foi escrito para o caso de Produção.
Por curiosidade, você pode compartilhar o que fez?
Eu escrevi um programa para verificar todas as postagens importadas para encontrar quais marcações/emoticons elas continham. Em seguida, escrevi outro programa para compilar as postagens brutas em HTML e atualizar o banco de dados diretamente.