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.
Qualcuno può spiegare come funziona questa versione di in_batches. Presumibilmente fa il re-bake in batch, ma dai post precedenti, è stato dichiarato che per impostazione predefinita esegue il rebake in batch di 100 ogni 15 minuti per impostazione predefinita.
Ho un lavoro di re-bake da 2 milioni da fare e sto cercando di capire il modo migliore per farlo. Il lavoro non ha urgenza, ma voglio assicurarmi che le operazioni normali e le operazioni amministrative (come il backup) non siano influenzate da un lavoro di lunga durata.
E ora ho appena letto questo post: Rebaked all my posts, but what's it doing now? che mi dice che l’attività di re-bake non li sta nemmeno ri-elaborando, ma li sta solo contrassegnando per la ri-elaborazione (come viene fatto questo contrassegno?). Il processo è così lento che faccio davvero fatica a credere che ci voglia così tanto tempo solo per contrassegnare un post per la ri-elaborazione.
Allora migra su un server più veloce.
Sii grato che non sovraccarichi il tuo sito. L’intero scopo è impedire che questo processo richieda troppe risorse, mantenendo il tuo sito reattivo durante il processo.
Consultare il codice sorgente è sempre una buona idea:
In effetti, il markup dovrebbe essere molto rapido. E il rebake_post sembra fare la chiamata alla cottura. Forse ci sono alcune attività asincrone che si verificano come parte di questo o come risultato di questo?
Sì, certo, è un lavoro che genera un set di lavori
Non è la soluzione ideale, ma ho trovato un altro modo!
Ho appena scritto il mio re-baker che è 1000 volte più veloce, quindi invece di impiegare un mese, ci vogliono solo pochi minuti.
In realtà farò il re-bake subito prima dell’inserimento nel database, in modo che il costo del re-bake scompaia nel tempo di inserimento nel db.
ah, ok non ero a conoscenza del tuo contesto.
sì, questo è scritto per il caso di produzione.
Per curiosità, puoi condividere cosa hai fatto?
Ho scritto un programma per analizzare tutti i post importati per trovare quali markup/smiley contenevano. Poi ho scritto un altro programma per creare i post grezzi in HTML e aggiornare direttamente il database.