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).
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')
Il metodo batch sarebbe adatto per un grande numero di rigenerazioni?
2851000 / 27182220 ( 10.5%)
Questo è il nostro processo attuale dopo averlo avviato ieri con il comando di rigenerazione normale; sembra elaborare circa 1000 elementi ogni 3 secondi. Siamo molto vicini alla fine del nostro percorso di importazione e dei test, e volevo solo assicurarmi che esista un modo più appropriato per rigenerare un sito di grandi dimensioni prima di accontentarci di questo metodo più lento.
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.