Je rencontre des erreurs, en avez-vous déjà vu et connaissez-vous une solution ? Je pensais que c’était un problème de mémoire sous Windows, mais cela se produit toujours même si j’ai 6 Go de libre sous Windows.
Ces erreurs sont intermittentes, mais se produisent assez souvent
Merci pour toute aide. À noter que si je réessaie, cela réussit généralement… De plus, il n’y a rien à ce sujet dans /logs
Notez que j’ai également ajouté des blocs de tuiles en vedette, mais si je désactive les blocs de la barre latérale droite, le problème disparaît. J’ai 11 Go de mémoire libre et beaucoup d’espace disque.
Si je désactive les tuiles en vedette et que j’active les blocs de la barre latérale droite, le problème persiste.
2 deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/top-contributors’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations
post.js:561 Utilisation du nouveau menu de publication ‘glimmer’ !
2deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/top-contributors’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations
Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 DÉPRÉCIATION : Les composants avec des templates résolus séparément sont dépréciés. Migrez vers des fichiers js/ts + hbs co-localisés ou vers gjs/gts. Tentative de recherche de ‘template:components/whos-online’. [id de dépréciation : component-template-resolving] Ceci sera supprimé dans ember-source 6.0.0. Voir Component Template Resolving | Ember.js - Deprecations pour plus de détails.
C’est peut-être la cause. Dans ce cas, vous êtes probablement limité par le débit.
Vous pourriez vérifier l’onglet réseau de la console du développeur, s’il y a plus de requêtes lorsque les blocs de la barre latérale droite sont activés.
(1) Je suis un administrateur, niveau de confiance 4, alors pourquoi « DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL » ne me permet-il pas de contourner les limitations de débit ?
Limitations de débit globales par adresse IP
Ces limites s’appliquent à chaque adresse IP unique qui accède à l’application Discourse. (les fichiers servis directement depuis le système de fichiers ou le CDN sont exclus)
Par défaut, cette limitation de débit est activée, vous pouvez la désactiver ou la définir en mode de rapport.
DISCOURSE_MAX_REQS_PER_IP_MODE : blocage par défaut, cette limitation de débit s’applique dès l’installation. (d’autres options sont avertir, avertir+bloquer et aucune)
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : nombre de requêtes par IP par minute (la valeur par défaut est 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : nombre de requêtes par IP par 10 secondes (la valeur par défaut est 50)
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS : nombre de requêtes d’assets (avatars/css) par IP par 10 secondes (la valeur par défaut est 200)
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE : la limitation de débit doit-elle s’appliquer aux adresses IP privées accédant à Discourse ? la valeur par défaut est false.
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL : utiliser les limitations de débit par utilisateur plutôt que par IP pour les utilisateurs ayant ce niveau de confiance ou plus (la valeur par défaut est 1)
Pour modifier les limites, ajoutez la modification souhaitée dans votre fichier app.yml dans la section env.
J’ai également vérifié le journal d’accès nginx, il affiche des adresses IP différentes pour nos utilisateurs. (J’ai vu dans un sujet beaucoup plus ancien où c’était un problème, tout le monde utilisait la même adresse IP pour l’accès)
Même avec les modifications décrites ci-dessus et après avoir reconstruit l’application, je vois l’avertissement de limite de débit dans la console du navigateur si j’active les blocs de la barre latérale droite.
Comment puis-je afficher ou déterminer la valeur réelle de, par exemple : DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL
De plus, si je désactive les blocs de la barre latérale droite, je ne vois aucun avertissement de limite de débit dans la console du navigateur si je parcours les sujets au même rythme qu’avec les blocs de la barre latérale droite activés.
Je suggère de chercher dans les discussions précédentes sur la limitation de débit.
Je ne suis pas un expert en la matière, mais si je comprends bien, la limitation de débit est appliquée en deux étapes : d’abord nginx effectue la limitation de débit (sans connaître les niveaux de confiance), puis l’application rails effectue une autre couche de protection.
Si vous souhaitez tester l’hypothèse selon laquelle vous rencontrez des limitations de débit au niveau de nginx, vous pouvez commenter la ligne suivante dans votre app.yml :
Je n’ai aucune limite de débit définie dans le nginx que j’utilise comme proxy inverse, et j’essaierai ce que vous suggérez pour voir ce que fait le conteneur.
Je charge le classement, les meilleurs producteurs et les événements dans les blocs de la barre latérale droite.
Je ferai un retour, merci.
Je parie que vous avez raison, alors quels sont les bons mais plus souples valeurs pour ces paramètres dans /var/discourse/templates/web.ratelimited.template.yml ? Est-ce simplement par essais et erreurs ?