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.
Quelqu’un peut-il expliquer comment fonctionne cette version in_batches. On suppose qu’elle effectue le re-cuisson par lots, mais d’après les messages ci-dessus, il est indiqué qu’elle effectue par défaut le re-cuisson par lots de 100 toutes les 15 minutes par défaut.
J’ai un travail de 2 millions de re-cuissons à faire et j’essaie de trouver la meilleure façon de le faire. Le travail n’est pas urgent, mais je veux m’assurer que le fonctionnement normal et les opérations administratives (comme la sauvegarde) ne sont pas affectés par un travail de longue durée.
Et maintenant, je viens de lire ce message : Rebaked all my posts, but what's it doing now? qui m’indique que la tâche de re-cuisson ne les re-cuit même pas, mais se contente de les marquer pour re-cuisson (comment cette marque est-elle faite ?). Le processus est si lent que j’ai vraiment du mal à croire qu’il faille autant de temps juste pour marquer un message pour re-cuisson.
Alors migrez vers un serveur plus rapide.
Soyez reconnaissant que cela ne submerge pas votre site. Le but est d’empêcher ce processus de prendre trop de ressources, en gardant votre site réactif pendant le processus.
Consulter la source est toujours une bonne idée :
En effet, le marquage devrait être très rapide. Et le rebake_post semble bien faire l’appel à la cuisson. Peut-être y a-t-il des tâches asynchrones qui se produisent dans le cadre de cela ou en conséquence ?
Oui, bien sûr, c’est une tâche qui génère un ensemble de tâches
Ce n’est pas la solution idéale, mais j’ai trouvé une autre façon !
J’ai écrit mon propre re-baker qui est 1000 fois plus rapide, donc au lieu de prendre un mois, cela ne prend que quelques minutes.
Je vais en fait refaire la cuisson juste avant l’insertion dans la base de données, de sorte que le coût de la refonte disparaîtra dans le temps d’insertion de la base de données.
ah, ok je n’étais pas au courant de votre contexte.
oui, ceci est écrit pour le cas de production.
Par curiosité, pouvez-vous partager ce que vous avez fait ?
J’ai écrit un programme pour analyser tous les messages importés afin de trouver les balises/smileys qu’ils contenaient. Ensuite, j’ai écrit un autre programme pour intégrer les messages bruts en HTML et mettre à jour la base de données directement.