Meine Reise in einen riesigen Post-Rebake-Job

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')

Wäre die Batch-Methode für eine große Anzahl von Neubearbeitungen geeignet?

2851000 / 27182220 ( 10.5%)

Das ist unser aktueller Prozess, nachdem wir ihn gestern mit dem normalen Neubearbeitungsbefehl gestartet haben. Es scheint, als würden etwa 1000 Einträge alle 3 Sekunden verarbeitet. Wir befinden uns kurz vor dem Ende unserer Import-Reise und der Testphase, und ich wollte nur sichergehen, dass es einen besseren Weg gibt, eine große Site neu zu bearbeiten, bevor wir uns für diese langsamere Methode entscheiden.

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.