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.
¿Alguien puede explicar cómo funciona esta versión de in_batches? Presumiblemente, hace el re-bake en lotes, pero de las publicaciones anteriores, se afirma que por defecto hace el re-bake en lotes de 100 cada 15 minutos por defecto.
Tengo un trabajo de re-bake de 2 millones para hacer y estoy tratando de encontrar la mejor manera de hacerlo. El trabajo no tiene urgencia, pero quiero asegurarme de que las operaciones normales y las operaciones administrativas (como la copia de seguridad) no se vean afectadas por un trabajo de larga duración.
Y ahora acabo de leer esta publicación: Rebaked all my posts, but what's it doing now? que me dice que la tarea de re-horneado ni siquiera los está volviendo a hornear, sino que solo los está marcando para volver a hornearlos (¿cómo se hace esta marca?). El proceso es tan lento que realmente me cuesta creer que lleve tanto tiempo solo marcar una publicación para volver a hornearla.
Entonces, migra a un servidor más rápido.
Agradece que no abrume tu sitio. El propósito es evitar que este proceso consuma demasiados recursos, manteniendo tu sitio receptivo durante el proceso.
Consultar la fuente siempre es una buena idea:
De hecho, el marcado debería ser muy rápido. Y el rebake_post parece hacer la llamada a la cocción. ¿Quizás hay algunas tareas asíncronas que ocurren como parte de esto o como resultado de esto?
Sí, por supuesto, es un trabajo que genera un conjunto de trabajos.
¡No es la solución ideal, pero encontré otra manera!
Acabo de escribir mi propio re-horneador que es 1000 veces más rápido, así que en lugar de tardar un mes, solo tarda unos minutos.
De hecho, volveré a hornear justo antes de la inserción en la base de datos, por lo que el costo de volver a hornear desaparecerá en el tiempo de inserción de la base de datos.
ah, ok no estaba al tanto de tu contexto.
sí, esto está escrito para el caso de Producción.
Por curiosidad, ¿puedes compartir lo que hiciste?
Escribí un programa para escanear todas las publicaciones importadas y encontrar las marcas/emoticonos que contenían. Luego escribí otro programa para procesar las publicaciones sin formato en HTML y actualizar la base de datos directamente.