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.
Kann mir jemand erklären, wie diese in_batches-Version funktioniert. Vermutlich werden die Rebakes in Batches durchgeführt, aber aus den obigen Beiträgen geht hervor, dass standardmäßig alle 15 Minuten Rebakes in Batches von 100 durchgeführt werden.
Ich habe einen 2-Millionen-Rebake-Job zu erledigen und versuche herauszufinden, wie ich das am besten mache. Der Job hat keine Eile, aber ich möchte sicherstellen, dass der normale Betrieb und administrative Operationen (wie Backups) nicht durch einen langlaufenden Job beeinträchtigt werden.
Und jetzt habe ich diesen Beitrag gelesen: Rebaked all my posts, but what's it doing now?, der mir sagt, dass die Re-Bake-Aufgabe die Beiträge nicht einmal neu backt, sondern nur für das erneute Backen markiert (wie geschieht diese Markierung?). Der Prozess ist so langsam, dass ich wirklich Schwierigkeiten habe zu glauben, dass es so lange dauert, nur einen Beitrag zum erneuten Backen zu markieren.
Dann migrieren Sie zu einem schnelleren Server.
Seien Sie dankbar, dass es Ihre Website nicht überfordert. Der ganze Sinn und Zweck ist es, zu verhindern, dass dieser Prozess zu viele Ressourcen beansprucht und Ihre Website während des Prozesses reaktionsfähig bleibt.
Es ist immer eine gute Idee, die Quelle zu konsultieren:
In der Tat sollte das Markieren sehr schnell gehen. Und das rebake_post scheint tatsächlich das Kochen aufzurufen. Möglicherweise gibt es dabei oder als Ergebnis davon asynchrone Aufgaben?
Ja, natürlich, es ist ein Job, der eine Reihe von Jobs erzeugt
Keine ideale Lösung, aber ich habe einen anderen Weg gefunden!
Ich habe gerade meinen eigenen Re-Baker geschrieben, der 1000x schneller ist, sodass er statt eines Monats nur wenige Minuten dauert.
Ich werde kurz vor der Datenbankeinfügung neu backen, sodass die Kosten für das erneute Backen innerhalb der Zeit für die Datenbankeinfügung verschwinden.
ah, ok war mir deines Kontexts nicht bewusst.
Ja, dies ist für den Produktionsfall geschrieben.
Aus reiner Neugier, können Sie mitteilen, was Sie getan haben?
Ich habe ein Programm geschrieben, das alle importierten Beiträge scannt, um herauszufinden, welche Markierungen/Smileys sie enthielten. Dann habe ich ein weiteres Programm geschrieben, um die Rohbeiträge in HTML zu konvertieren und die Datenbank direkt zu aktualisieren.