Mi sugerencia sería evaluar productos de chat con el objetivo de integrarlos de manera fluida.
Ephemera no pertenece a Discourse.
Mi sugerencia sería evaluar productos de chat con el objetivo de integrarlos de manera fluida.
Ephemera no pertenece a Discourse.
Debes tener mucho cuidado aquí. Tal vez convenga tener un solo tema de ‘chat’ a la vez y eliminar los antiguos con estricta regularidad, ya que cada megatema que sigue existiendo impone una penalización de rendimiento intensa al servidor, y dicha penalización aumenta con cada visita a una página.
Lo mejor es integrar una herramienta de chat real, según:
Estoy 100% de acuerdo con esto. A veces añaden valor a la comunidad, pero no en la medida que justifique cambios en el código, en mi opinión.
¿Podrías ampliar un poco esta penalización de rendimiento? ¿Se aplica a temas cerrados y archivados? Cerrar temas al llegar a 10k está bien, pero eliminarlos sería algo completamente distinto.
A mi comunidad le encanta Discourse y lleva más de 15 años basada en foros. No usarán una sala de chat y reaccionarían muy negativamente si se eliminan los temas antiguos. Si va a haber un problema de rendimiento serio y creciente simplemente porque estos temas existen, tendré que convertirlos en páginas estáticas o migrar a otra plataforma.
Sé que nuestra comunidad no encaja bien con la forma en que ustedes visualizan el uso de Discourse, pero esa es la comunidad de la que soy responsable y hay cambios que no puedo imponerles. De hecho, nunca hemos estado más fuertes como comunidad que ahora, usando Discourse. Me gustaría evitar tener que mudarnos a otra plataforma cuando todos están tan contentos con nuestra configuración actual.
Los megatemas deben estar mayormente ocultos: incluso si están cerrados y/o archivados, cuantos más usuarios accedan a un megatema, peor será el rendimiento de tu servidor. Idealmente, los megatemas deberían eliminarse para que solo tengas uno activo en cualquier momento. Esa es mi recomendación. Cuantos más megatemas tengas, mayor será el riesgo que asumes.
Si puedes invertir una buena cantidad de dinero en el problema, podrías sobreaprovisionar masivamente tu servidor y soportar más megatemas, pero aun así afectará el rendimiento mediano de todos los temas.
Incluso cuando un tema está cerrado, genera datos, tráfico y carga.
Recuerda que la posición de lectura de cada usuario se registra para cada tema. Cada publicación puede recibir “me gusta”, la interacción con megatemas sigue siendo posible incluso después de que se cierren, sin mencionar la cantidad de ruido que pueden introducir en tus resultados de búsqueda.
Eso aún no explica por qué los megatemas en particular causan problemas. ¿Por qué un tema de 10.000 publicaciones es peor que diez temas de 1.000 publicaciones cada uno? En el segundo caso, hay el mismo número total de publicaciones que podrían recibir un «me gusta» o ser buscadas, pero diez veces más posiciones de lectura y temas que buscar. Basándome únicamente en tu explicación, concluiría que un mayor número de temas más pequeños es peor. Por lo tanto, debe haber algo más en juego.
Porque estás cargando solo un tema a la vez. Puedes recoger 10 temas de 1.000 <inserta algo ligero aquí> uno a la vez sin problemas, pero recoger 10.000 de una vez es mucho más difícil.
Sin embargo, me intrigan los detalles específicos. Solo se cargan ciertos números de publicaciones por defecto antes de hacer scroll, así que claramente no se debe al número de publicaciones visibles. ¿Se debe a la línea de tiempo? ¿Al resumen del tema? ¿O en general a varios algoritmos lineales o superlineales basados en el número total de publicaciones en el tema?
No me importan mucho los megatemas, dependiendo de lo que consideres “mega”. En la sección que frecuento más en la comunidad que uso, el tema con más publicaciones tiene alrededor de 3.6 mil, pero el décimo más alto tiene solo 600. El vigésimo quinto más alto tiene solo 300 publicaciones. En este momento, me interesa más desde una perspectiva técnica.
Aquí tienes una consulta del explorador de datos que escribí para intentar responder a tu pregunta. Puedes probarla con diferentes temas y desplazamientos.
-- [params]
-- int :topic_id = 107216
-- int :offset = 10000
SELECT "posts"."id" FROM "posts"
WHERE ("posts"."deleted_at" IS NULL)
AND "posts"."topic_id" = :topic_id
AND "posts"."post_type" IN (1,2,3) ORDER BY "posts"."sort_order" ASC LIMIT 20
OFFSET :offset
Aquí hay un tema de tamaño normal y un tema enorme:
Tiempo de ejemplo: 3.4ms
-> Escaneo de índice usando index_posts_on_topic_id_and_sort_order en posts (cost=0.43..1925.22 rows=477 width=8)
tiempo de ejemplo: 353.9ms, 739.6 ms (el tiempo varía según la caché de la base de datos)
-> Escaneo de índice usando index_posts_on_topic_id_and_sort_order en posts (cost=0.43..605155.88 rows=161255 width=8)
Creo que he visto tiempos superiores a 750 ms.
Aquí están los tiempos de la mediana y del percentil 99. El tiempo de la mediana es sorprendentemente bueno, pero la naturaleza de una mediana es que no puedes saber si, en el percentil 60%, es mucho, mucho peor que el caso mediano.
Aquí hay otro servidor (tiene un número enorme de categorías, lo que también le afecta al rendimiento, por lo que no es una comparación directa sin megatemas), pero puedes ver que el rendimiento mediano es la mitad y el peor caso también es mucho mejor:
Yo también, solo por curiosidad.
Entiendo que navegar en un megahilo podría tener un rendimiento deficiente según esta explicación:
Sin embargo, no entiendo cómo uno o varios megahilos pueden afectar la navegación en otras páginas del foro, como la lista de hilos, por ejemplo. ![]()
Al agregar mucha carga al servidor. ¡Cada carga de megatema individual equivale a una penalización de rendimiento 100 veces mayor! Consulta la publicación justo encima de la tuya.
Hola,
El foro que estoy importando actualmente a Discourse tiene muchos temas gigantes:
Dado que los temas gigantes no funcionan bien con Discourse, ¿qué debería hacer en la práctica? (Tengo la intención de sugerir un chat en el futuro para la comunidad, quizás Discord, pero quiero saber qué hacer con los temas actuales).
¿Borrarlos?
¿Dividirlos y cerrarlos?
Si los divido, ¿cuántos mensajes por tema? ¿Es el valor predeterminado de 10000 suficiente o quizás recomiendan reducirlo?
Dividir en 10 mil fragmentos debería ser suficiente.
Además, la mayoría de esas se ven bien. La verdadera sangría comienza en 10k y la mayor parte de lo que se muestra en la captura de pantalla es mucho menos de 10k.
¿Cuál es la última información sobre el impacto en el rendimiento del mega tema? Nuestro tema de seguimiento de la pandemia de COVID se acerca a las 10 mil publicaciones y estamos analizando posibles ralentizaciones recientes.
No sé cuáles deberían ser las estadísticas del servidor, pero puedo compartir las nuestras para una comunidad con muchos megatemas. Actualmente tenemos 15 temas cerrados con 10.000 publicaciones y más de 50 abiertos con más de 2.000 publicaciones. La mayor parte de la actividad del foro ocurre en un número relativamente pequeño de temas muy activos en cualquier momento dado.
Actualmente funcionamos en un servidor de DigitalOcean con 4 CPUs virtuales, 8 GB de memoria y 160 GB de disco, lo que cuesta 40 dólares al mes. Quizás una vez cada pocos meses algunos usuarios reciban muy brevemente el mensaje de “carga extrema”. Esto solo ocurre cuando hay algún evento en vivo y muchos usuarios están publicando al mismo tiempo, como promediar varias publicaciones por minuto en un solo tema durante una o dos horas.
En todo otro momento, el rendimiento es fluido y sin problemas. Actualmente estamos en camino de necesitar más espacio en disco mucho antes de necesitar actualizar cualquier otra cosa.
Ese es un número razonable; 2 mil publicaciones no es gran cosa, y un par de docenas de temas de más de 10 mil probablemente esté bien (especialmente si están cerrados). La zona de peligro es cuando tienes muchos megahilos activos. Definiría “muchos” como más de unas pocas docenas.
Aunque los temas masivos generalmente no son un problema aquí en Meta, parecen ser una forma natural de organizar discusiones para muchas comunidades. En otras palabras, la discusión no tiene un punto de ruptura natural.
Inderes es una empresa finlandesa que proporciona análisis financiero para el mercado de valores. Recientemente lanzaron su comunidad en Discourse y ha sido un éxito masivo, considerando la región y el nicho.
La discusión se organiza principalmente por acción o vehículo de inversión. Por ejemplo, $AAPL o $TSLA. Ahora, en solo dos años aproximadamente, muchos de estos temas se están acercando al marcador de 10 mil. Una prueba de concepto fantástica para Discourse (una comunidad vibrante, construida desde cero), pero que también resalta el problema de los temas masivos.
Si nada más, puedes dividirla por año. Esto se explica en el primer mensaje. Los megatemas pueden funcionar por un tiempo, pero si hay demasiados, eventualmente harán que tu sitio colapse.
(También, la búsqueda se convierte en una pesadilla cuando tienes decenas de miles de mensajes en el mismo “tema”, etc. Básicamente, has construido una sala de chat.)