C’est une bonne spécification ! Vous devez avoir un site particulièrement fréquenté ?
Êtes-vous sûr qu’il n’y a pas eu de nouveau rendu ?
Combien d’images sont publiées par minute ?
La préparation des miniatures est principalement du code de base et nécessite un traitement d’image supplémentaire obligatoire.
Ce serait le cas pour tout composant de plugin ou de thème de cette nature.
Nous avons désactivé le plugin pendant environ 24 heures, puis nous l’avons réactivé pendant 24 heures.
Ci-dessous, je copie-colle les notes de notre autre administrateur.
Le plugin ralentit la planification des tâches.
Plus il y a de tâches dans la file d’attente, plus le processeur a du mal à suivre.
Le serveur reçoit donc beaucoup de trafic, mais tout semble normal pendant un certain temps jusqu’à ce que les tâches commencent à s’accumuler.
Finalement, le processeur a du mal à suivre et son utilisation augmente et diminue à mesure qu’il traite les tâches en attente.
C’est pourquoi nous avons vu plus tôt qu’il y avait plus de 3000 tâches en attente.
Dans des circonstances normales, il n’y a jamais plus de 5 tâches. Mais il y en a presque toujours 0 car aucune tâche ne devrait être en attente, elles devraient être traitées immédiatement.
L’image ci-jointe montre les tâches actuelles en attente. Actuellement, il y en a entre 30 et 35 en attente.
Toutes les tâches sont nouvelles depuis le dernier message dans le sidecar.
Je ne peux pas encore dire pourquoi, mais cela ne se produit que lorsque le plugin est activé.
Dernière heure des ressources CPU
Dernières 24 heures, indiquant approximativement où le plugin a été activé (voir la tendance à la hausse après le pic)
Il semble que le schéma soit plus long que 24 heures pour être remarqué, mais le plugin provoque une utilisation générale des ressources de 80 à 90 % la plupart du temps.
Une fois que nous l’aurons désactivé, nous remarquerons que pendant les prochaines 24 heures, le serveur utilisera en moyenne 60 à 75 % de ses ressources et que les tâches ne seront pas en attente.
De plus, lorsque nous le souhaiterons, j’ai modifié le fichier app.yml pour avoir 16 workers unicorn. Lorsque nous voudrons reconstruire, je pense que nous devrions désactiver le plugin et avoir 16 workers unicorn. Nous observerons les performances du serveur pendant cette période et ajusterons la valeur des workers à ce que nous jugeons le meilleur.
Sur les 7 derniers jours
rouge = activé
bleu = désactivé
Après avoir réactivé le plugin, le CPU est en pic. Je suis moins confiant quant à l’importance du problème des tâches. J’ai remarqué que le nombre de tâches augmente avec plus de workers unicorn. Je pense que le nombre n’est pas lié.
Je constate toujours le problème du plugin qui retient des ressources.
Je ne suis toujours pas sûr à 100%, mais je suis très confiant que le plugin pose problème.
plugin + 16 workers : bloque le serveur
16 workers sans plugin - fonctionne bien
plugin + 8 workers - lent mais ça fonctionne
graphique après la désactivation du plugin
Salut,
Je suis l’autre administrateur qui a pris ces notes.
Je ne vois plus les jobs comme faisant partie du problème.
Malheureusement, je ne connais pas très bien le fonctionnement interne de Discourse pour savoir quelle pourrait en être la cause. Je sais seulement ce que je vois actuellement.
On peut résumer cela en disant que le site est généralement lent lorsqu’il est activé avec 8 workers et qu’il plante presque avec 16 workers.
Lorsque le plugin est désactivé, le site fonctionne parfaitement bien et avec suffisamment de workers, il est très rapide.
Cela me fait penser qu’il y a quelque chose dans le plugin qui ralentit le site, soit par manque de ressources, soit par quelque chose qui est bloqué dans des opérations d’E/S ou asynchrones, peut-être.
Veuillez vérifier votre file d’attente sidekiq. Voyez-vous beaucoup de tâches mises en file d’attente et quels sont les noms des tâches ?
Je suis sûr qu’il s’agit simplement d’un arriéré de production de miniatures qui se résoudra une fois que toutes les images auront été traitées.
C’est un processus de base.
Vous pouvez supprimer en toute sécurité le plugin sidecar si vous n’avez pas besoin de ses fonctionnalités supplémentaires et utiliser uniquement le composant de thème.
Pouvez-vous confirmer que le problème persiste avec le composant de thème actif mais pas le plugin sidecar ?
Si vous n’avez jamais eu le plugin sidecar installé, le problème doit être dans le cœur du système.
Si vous avez besoin d’aide pour votre analyse, vous pouvez engager Pavilion.
J’accueille les rapports indépendants de ce problème.
Juste pour confirmer - une augmentation des tâches de redimensionnement d’images à forte utilisation de CPU est attendue lorsque vous activez un quelconque composant de thème pour les miniatures de listes de sujets 
. Le cœur génère les miniatures « à la demande » pour le premier utilisateur qui consulte un sujet donné dans une liste de sujets.
Comme l’a mentionné @merefield, cela devrait se stabiliser une fois que toutes les miniatures auront été générées pour les sujets fréquemment listés.
Augmenter le nombre de workers n’est probablement pas une bonne idée - essayer de faire plus de travail en parallèle sur une machine limitée en CPU ne fera qu’aggraver les symptômes. Il est préférable de maintenir le nombre de workers normal afin que les tâches puissent être mises en file d’attente et traitées sans surcharger la machine.
Dans l’interface utilisateur de Sidekiq, vous voudrez probablement regarder les onglets « Busy » et « Queued ». Les tâches « Scheduled » sont celles planifiées pour une heure spécifique dans le futur, elles sont donc très peu susceptibles de causer des problèmes de performance.
Cela rend très bien en aperçu, mais en réalité, c’est complètement différent. Qu’est-ce que je fais de mal ?
De nombreux thèmes de « conversion totale » ne sont pas pris en charge. Je soupçonne que FKB Pro a ses propres remplacements qui entrent en conflit avec ce composant. Je crains de ne pas pouvoir prendre en charge ce scénario.
Ce composant de thème est destiné à être utilisé comme bloc de construction au sein d’un thème qui n’essaie pas de couvrir toutes les bases.
Si vous souhaitez une barre latérale droite avec des aperçus de la liste des sujets, essayez Blocs de barre latérale droite en combinaison.
Il y a un petit problème de CSS/espacement entre l’en-tête du sujet et l’icône du lien mis en avant.
Ajout d’une fonctionnalité expérimentale :
Cela fonctionne assez bien maintenant, toujours derrière un réglage :
Ceci est réactif à la largeur, donc n’apparaît en mode Tuiles (mosaïque) que lorsque la zone de liste est suffisamment large.
Démo ici : https://www.starzen.space/
NB Le rembourrage excessif en bas à droite est un problème connu et nécessaire en raison du rendu en mosaïque qui, pour des raisons de performance (c’est rapide !), rend les choses à la ligne de grille la plus proche. Une fois (!) qu’ils implémenteront la mosaïque native dans la grille CSS, je vais refactoriser cela pour le rendre plus agréable.
NB#2 La capture d’écran contient également des contrôles du composant de thème Discourse Bars (la barre latérale est masquée). Topic List Previews fonctionne très bien avec Discourse Bars.
Une image pour YouTube apparaît sur la page d’accueil.
Pourrait-elle aussi être pour Twitter ?
Il n’est en aucun cas limité à YouTube.
Il expose tout ce que la miniature représente. Si l’intégration Twitter crée une miniature, alors oui.
Pourriez-vous s’il vous plaît me dire quels paramètres je devrais choisir pour que cela ressemble à cette image ?
Je veux que ce soit sous la forme d’une liste de miniatures comme sur cette image.
image alignée à gauche
Supprimez les routes de ce paramètre :
Sinon, elles s’afficheront sous forme de « Tuiles ». Si vous souhaitez que zéro route soit au format « Tuiles », supprimez toutes ces lignes, mais vous pourriez envisager les Tuiles sur mobile (auquel cas conservez celles avec *-mobile).
C’est parfait maintenant, merci 
Il existe un paramètre dans le plugin sidecar associé (listé dans le OP) :
Mais sans le plugin, vous pourriez vouloir essayer les paramètres natifs :
Je n’ai pas regardé ça depuis un moment ! 
J’essaie les paramètres que vous avez mentionnés, mais cela ne fonctionne pas.
Fait intéressant, il y a trop peu de résumés sur un sujet et trop sur l’autre.
Le caractère doit être dans une certaine limite de caractères.
Installez le plugin sidecar, utilisez ce paramètre.
Je suppose que vous devez déclencher un nouveau rebaking pour refaire le résumé du sujet.
