Tenemos 5 millones de publicaciones y la búsqueda es bastante rápida. Estamos alojados en 6 núcleos compartidos de un Xeon E5-2680 de 2.8 GHz con 16 GB de RAM y almacenamiento SSD. Dicho esto, no tengo métricas sobre cuántas publicaciones simultáneas inician nuestros usuarios; podría haber problemas de bloqueo.
Publicar, por otro lado, a menudo es bastante lento. Puede tardar de 6 a 7 segundos en procesarse una publicación. Discourse no bloquea el sistema mientras procesa, por lo que esto no afecta la experiencia del usuario.
¿Son específicos los tiempos de publicación de 6-7 segundos para los temas masivos? Si respondes a un tema con 100 respuestas, ¿también toma de 6 a 7 segundos?
No pude reproducirlo justo ahora; la publicación lenta es intermitente. No parece correlacionarse con la cantidad de publicaciones en el hilo. Quizás sea un problema de bloqueo por otra persona publicando simultáneamente o algo así.
7 publicaciones = muy rápido, aproximadamente igual que aquí en meta
500 publicaciones = quizás un poco más lento, no demasiado malo. ¿Quizás 1.5 segundos?
16k publicaciones = parece aproximadamente lo mismo que con 500
Y creo que el rendimiento también se ve afectado si un grupo de personas accede a un tema masivo, lo que ralentiza todo el servidor PG con solicitudes en cola.
¿Qué tan valiente te sientes? ¿Te importaría habilitar mini_profiler por un momento? Esto te mostrará los tiempos a un lado, y así podremos aislar qué consulta te está dando problemas.
¿Cuánto afecta la activación al rendimiento general? ¿Y se puede activar sin una reconstrucción del sitio? No he logrado que una reconstrucción tenga éxito desde el cambio a PostgreSQL 12, incluso configurándolo para que se mantenga en pg10.
Necesitas configurar tu dirección de correo electrónico como el correo del desarrollador en el archivo app.yml. Puedes aplicarlo sin recompilar destruyendo y reiniciando el contenedor. Si has realizado cambios en el contenedor al actualizar con Discourse Docker, estos se perderán.
También puedes editar config/discourse.conf dentro del contenedor y luego
Dado que las reconstrucciones están fallando, mi preocupación es que si destruyo el contenedor, me quedaré completamente sin opciones. Tuve tantos errores al intentar la actualización a pg12 ayer que realmente no me siento cómodo haciendo cambios hasta tener la confianza de que no dejaré el sitio fuera de servicio por un período prolongado.
Bueno, el consejo gratuito vale lo que pagas por él, pero es bastante seguro ejecutar:
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# en vi, edita la línea developer_emails para incluir tu dirección de correo electrónico y sal de vi
sv unicorn restart
# entra en pánico durante los 30-90 segundos que tarda el servidor web en reiniciarse y comenzar a servir páginas
Sin embargo, aún podrías romper algo de esta manera. Creo que es posible dañar ese archivo de configuración de tal forma que Discourse no inicie.
¿Es esto lo que necesitabas? Esto se está publicando en un hilo con 16 mil publicaciones. Parecía un momento normal para publicar, no particularmente lento.
¡Genial! Cualquier mejora sustancial en el tiempo de publicación hará muy felices a nuestros usuarios; de momento, es lo que más se critica. Aunque no tengo ninguna duda de que pronto encontrarán algo más por lo que quejarse.
Si te sirve de consuelo, yo también me quejé de esa consulta, porque tengo un estado de lectura tan alto aquí en Meta. Estamos haciendo un trabajo inútil contando cosas en cada respuesta…
En nuestra prueba de importación desde otro software, tenemos un tema con un poco más de 200.000 publicaciones y pude publicar en él sin problemas. Debe ser porque lo que importa no es el tamaño del tema, sino el usuario que realiza la publicación.
