¡Esa es una buena especificación! ¿Debes tener un sitio particularmente ocupado?
¿Estás seguro de que no hubo ningún rebake?
¿Cuántas imágenes se publican por minuto?
La preparación de miniaturas es principalmente código central y requiere un procesamiento de imágenes adicional obligatorio.
Este sería el caso de cualquier complemento o componente de tema de esta naturaleza.
Desactivamos el plugin durante aproximadamente 24 horas y luego lo volvimos a activar durante 24 horas.
A continuación, pego las notas de nuestro otro administrador.
El plugin está provocando que los trabajos programados se ralenticen.
Cuantos más trabajos hay en la cola, más le cuesta a la CPU mantenerse al día.
Así que lo que sucede es que el servidor ve mucho tráfico, pero las cosas parecen normales durante un tiempo hasta que los trabajos comienzan a acumularse.
Finalmente, la CPU tiene dificultades para mantenerse al día y el uso aumenta y disminuye a medida que completa los trabajos atrasados.
Por eso vimos antes que había más de 3000 trabajos atrasados.
En circunstancias normales, nunca hay más de 5 trabajos. Pero casi siempre hay 0 porque no debería haber trabajos atrasados, deberían procesarse de inmediato.
La imagen adjunta muestra los trabajos actuales que se están acumulando. Ahora mismo, se mantiene entre 30 y 35 trabajos atrasados.
Todos los trabajos son nuevos desde la última publicación en el sidecar.
Aún no puedo decir por qué, pero esto solo sucede cuando el plugin está activado.
Última hora de los recursos en la CPU
Últimas 24 horas, señalando aproximadamente dónde se activó el plugin (ver la tendencia ascendente después del pico)
Parece que el patrón es más largo de 24 horas para notarlo, pero el plugin causa un uso general de recursos del 80-90+% la mayor parte del tiempo.
Una vez que lo desactivemos, notaremos que durante las próximas 24 horas el servidor promediará entre el 60 y el 75% y los trabajos no se acumularán.
Además, cuando queramos, cambié el app.yml para tener 16 workers de unicorn. Cuando queramos reconstruir, creo que deberíamos deshabilitar el plugin y tener 16 workers de unicorn. Observaremos el rendimiento del servidor durante ese período de tiempo y ajustaremos el valor de los workers a lo que creamos que es mejor.
Últimos 7 días
rojo = activado
azul = desactivado
Después de volver a activar el plugin, la CPU está experimentando picos. Tengo menos confianza en que la parte de los trabajos sea importante. Noté que el recuento de trabajos aumenta con más workers de unicorn. Creo que el número no está relacionado.
Todavía veo el problema de que el plugin retiene recursos.
Todavía no estoy 100% seguro, pero confío mucho en que el plugin es un problema.
plugin + 16 workers: bloquea el servidor
16 workers sin plugin - funciona bien
plugin + 8 workers - lento pero funciona
gráfico después de desactivar el plugin
Hola,
Soy el otro administrador que tomó esas notas.
Ya no veo que los trabajos sean parte del problema.
Desafortunadamente, no tengo muchos conocimientos sobre el funcionamiento interno de Discourse para saber cuál podría ser la causa. Solo sé lo que veo actualmente.
Se puede resumir en que el sitio es generalmente lento cuando está habilitado con 8 workers y casi se cae con 16 workers.
Con el plugin desactivado, el sitio funciona perfectamente y con suficientes workers es muy rápido.
Esto me lleva a creer que hay algo en el plugin que está ralentizando el sitio, ya sea por recursos o por algo que se está reteniendo en operaciones de E/S o asíncronas, quizás.
Por favor, revisa tu cola de sidekiq. ¿Ves muchos trabajos en cola y cuáles son los nombres de los trabajos?
Estoy seguro de que es solo un retraso en la producción de miniaturas que se resolverá una vez que se hayan procesado todas las imágenes.
Ese es un proceso central.
Puedes eliminar de forma segura el plugin sidecar si no necesitas sus funciones adicionales y simplemente usar el Componente de Tema.
¿Puedes confirmar que el problema persiste con el Componente de Tema activo pero sin el plugin sidecar?
Si nunca has tenido instalado el plugin sidecar, entonces el problema debe estar en el núcleo.
Si necesitas ayuda con tu análisis, puedes contratar a Pavilion.
Agradezco informes independientes sobre este problema.
Solo para confirmar: se espera un aumento en los trabajos de redimensionamiento de imágenes con uso intensivo de CPU cuando habilite cualquier componente temático de miniaturas de listas de temas 
. El núcleo genera las miniaturas ‘bajo demanda’ para el primer usuario que ve un tema dado en una lista de temas.
Como mencionó @merefield, debería estabilizarse una vez que se hayan generado todas las miniaturas para los temas listados con frecuencia.
Aumentar el número de trabajadores probablemente no sea una buena idea: intentar hacer más trabajo en paralelo en una máquina con restricciones de CPU empeorará los síntomas. Es mejor mantener los números de trabajadores como normales para que los trabajos puedan ponerse en cola y procesarse sin sobrecargar la máquina.
En la interfaz de usuario de Sidekiq, probablemente querrá observar las pestañas “Ocupado” y “En cola”. Los trabajos “Programados” son los programados para una hora específica en el futuro, por lo que es muy poco probable que causen problemas de rendimiento.
Se ve genial en la vista previa, pero en realidad es completamente diferente. ¿Qué estoy haciendo mal?
Muchos temas de “conversión total” no son compatibles. Sospecho que FKB Pro tiene sus propias anulaciones que entran en conflicto con este componente. Me temo que no puedo admitir este escenario.
Este componente temático está diseñado para ser utilizado como un bloque de construcción dentro de un tema que no intenta cubrir todas las bases.
Si desea una barra lateral derecha con vistas previas de la lista de temas, pruebe Right Side Blocks en combinación.
Hay un pequeño problema de CSS/espaciado entre el encabezado del tema y el icono de enlace destacado.
Se agregó una función experimental:
Esto está funcionando bastante bien ahora, todavía detrás de una configuración:
Esto responde al ancho, por lo que solo aparece en el modo Mosaico (masonry) cuando el área de la lista es lo suficientemente ancha.
Demostración aquí: https://www.starzen.space/
NB El relleno excesivo en la parte inferior derecha es un problema conocido y necesario debido al renderizador de mosaico que, por razones de rendimiento (¡es rápido!), renderiza las cosas en la fila de la cuadrícula más cercana. Una vez (!) que implementen el mosaico nativo en la cuadrícula CSS, refactorizaré esto para que sea más agradable.
NB#2 La captura de pantalla también contiene algunos controles del componente temático Discourse Bars (la barra lateral está oculta). Topic List Previews funciona muy bien con Discourse Bars.
Una imagen para YouTube aparece en la página de inicio.
¿Podría ser también para Twitter?
No está restringido de ninguna manera a YouTube.
Expone lo que sea que sea la miniatura. Si la incrustación de Twitter crea una miniatura, entonces sí.
¿Podrías decirme qué configuración debería elegir para que se vea como en esta imagen?
Quiero que tenga el formato de una lista de miniaturas como en esta imagen.
imagen alineada a la izquierda
Elimina las rutas de esta configuración:
De lo contrario, se mostrarán como “Tiles”. Si quieres cero rutas en formato “Tiles”, elimina todas estas líneas, pero podrías considerar Tiles en móvil (en cuyo caso conserva las que tienen *-mobile).
Ya está perfecto, gracias 
Hay una configuración en el plugin complementario sidecar (listado en el OP):
Pero sin el plugin, es posible que desees probar la configuración nativa:
¡No he mirado esto en mucho tiempo! 
Estoy jugando con la configuración que mencionaste, pero no funciona.
Curiosamente, hay muy pocos resúmenes sobre un tema y demasiados sobre el otro.
El personaje debe estar dentro de un cierto límite de caracteres.
Instala el plugin sidecar, usa esa configuración.
Supongo que tienes que disparar un nuevo horneado de publicaciones para rehacer el resumen del tema.
