Sin embargo, tengo un par de preguntas al respecto:
¿Hay una forma más nueva de hacer esto?
Si quisiera cerrar basándome en la fecha de la última actividad (en lugar de la fecha de creación), ¿hay alguna variable que pueda usar en lugar de created_at?
¿Hay alguna forma de excluir los mensajes directos (DMs) del cierre? Ejecuté la consulta en mi entorno de prueba y noté que afectaba a todos los temas, ya fueran públicos o privados; nos gustaría excluir los mensajes privados si es posible.
En nuestro foro, tenemos casi 16 años de contenido que importamos de nuestra solución anterior. En cuanto al tiempo de ejecución de la consulta, (a) ¿cómo podemos determinar cuánto tiempo necesita ejecutarse y (b) sería mejor dividirla (por ejemplo, ejecutarla para todo lo anterior a 2010, luego para 2011, 2012, etc., hasta llegar a 2023) o simplemente ejecutarla como una sola consulta?
Solo estoy tratando de asegurarme (con el punto #4) de no afectar demasiado el rendimiento del sistema. Sé que mucho depende del hardware en el que estamos ejecutando (que en realidad no conozco, porque tenemos un equipo de infraestructura que se encarga de la instalación y mantiene todo el hardware).
En el #2, usando el plugin explorador de datos (del cual no tenía conocimiento), parece que updated_at es probablemente el valor donde estaría la ‘marca de tiempo de la última respuesta’. ¿Es esa una evaluación precisa?
Gracias por este consejo, creo que es muy útil para mis tres primeras preguntas. Agradecería algo de claridad sobre updated_at y la planificación para operar con nuestro historial extendido de publicaciones y temas.
Definitivamente probaría primero con un lote pequeño. Yo, eh, he caído un sitio comunitario con acciones masivas y desearía haber probado un subconjunto primero.
Gracias, sospechaba que ese podría ser el caso. Es bueno tener confirmación sobre el enfoque.
Creo que lo que haré es intentar extraer una de las copias de seguridad recientes y configurar un entorno sandbox separado de mi entorno de prueba. No estoy seguro de cómo funcionará la pieza SSO en esa configuración, pero sería bueno ver cómo se ve el rendimiento antes de afectar al sistema de producción.
Lo tendré en cuenta si tienes una comunidad especialmente activa, el sitio de prueba no simulará completamente la producción, ya que hay cierto impacto de las personas que usan el sitio orgánicamente además de las acciones masivas.
Definitivamente, aprecio también la indicación a la publicación del servidor de staging, eso será de gran ayuda.
Sí, la carga de usuarios no es probable que sea un gran problema; parece que nuestras vistas de página por día son alrededor de 50K en promedio entre todos (rastreadores, anónimos y usuarios registrados). Comprender la posible carga aumentada sobre la carga existente será útil para fines de planificación.
Configuré un servidor de staging (fue bastante fácil, en realidad: restauré una copia de seguridad de producción e inicié sesión usando el procedimiento de recuperación de administrador, ya que está configurado solo para OIDC). Parece que tenemos alrededor de 160.000 temas, y una prueba rápida en una sola categoría con alrededor de 7.500 tomó 6 minutos en mi sistema de prueba, por lo que unas 2 horas para todos los temas. El impacto en el rendimiento del sistema (monitoreado con htop) pareció bastante insignificante aquí.
Estoy seguro de que podemos encontrar un período de bajo uso donde se pueda ejecutar el comando rake, y podemos organizar grupos de categorías si queremos, así que eso funcionará muy bien para nosotros.
Agradezco todos los consejos y la ayuda: he aprendido mucho sobre la plataforma en los últimos días como resultado.
