مشاكل عندما أشرِّح المكوِّن، ربما كتل الشريط الجانبي الأيمن؟

[sandra.mccollum]

أواجه بعض الأخطاء، هل رأيتموها وتعرفون أي حل؟ اعتقدت أنها مشكلة في ذاكرة ويندوز، لكنها لا تزال تحدث إذا كان لدي 6 جيجابايت مجانية في ويندوز.

عند العودة من موضوع

عند الذهاب إلى موضوع:

هذه الأخطاء متقطعة، لكنها تحدث كثيرًا

شكرًا على أي مدخلات. ليس أنه إذا حاولت مرة أخرى، فإنها تنجح عادةً… أيضًا، لا يوجد شيء عن هذا في /logs

لاحظ أنني أضفت أيضًا “Featured Tiles”، ولكن إذا قمت بتعطيل “Right Sidebar Blocks”، تختفي المشكلة. لدي 11 جيجابايت من الذاكرة المجانية والكثير من مساحة القرص.

إذا قمت بتعطيل “Featured Tiles” وتمكين “Right Sidebar Blocks”، تستمر المشكلة.

[toanvoc (Toan Nguyen)]

لدي نفس الخطأ ولكن لا أعرف كيف أصلحه على الرغم من أنني نشرته هنا

[sandra.mccollum]

لنأمل أن يكون لدى شخص ما فكرة

[thoka (Thomas Kalka)]

سأبحث في وحدة تحكم المتصفح عن الأخطاء.

[sandra.mccollum]

لقد تلقيت 1100 سطر، إليك جزء منها:

2 deprecation-identify-source.js:15 تحذير: المكونات ذات القوالب التي يتم حلها بشكل منفصل هي الآن قيد الإهمال. قم بالترحيل إما إلى ملفات js/ts + hbs المتجاورة أو إلى gjs/gts. حاولت البحث عن ‘template:components/top-contributors’. [معرف التحذير: component-template-resolving] سيتم إزالة هذا في ember-source 6.0.0. انظر Component Template Resolving | Ember.js - Deprecations

post.js:561 استخدام قائمة ‘glimmer’ الجديدة للمنشورات!
2deprecation-identify-source.js:15 تحذير: المكونات ذات القوالب التي يتم حلها بشكل منفصل هي الآن قيد الإهمال. قم بالترحيل إما إلى ملفات js/ts + hbs المتجاورة أو إلى gjs/gts. حاولت البحث عن ‘template:components/top-contributors’. [معرف التحذير: component-template-resolving] سيتم إزالة هذا في ember-source 6.0.0. انظر Component Template Resolving | Ember.js - Deprecations

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Too Many Requests)

Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 تحذير: المكونات ذات القوالب التي يتم حلها بشكل منفصل هي الآن قيد الإهمال. قم بالترحيل إما إلى ملفات js/ts + hbs المتجاورة أو إلى gjs/gts. حاولت البحث عن ‘template:components/whos-online’. [معرف التحذير: component-template-resolving] سيتم إزالة هذا في ember-source 6.0.0. انظر Component Template Resolving | Ember.js - Deprecations لمزيد من التفاصيل.

[thoka (Thomas Kalka)]

@sandra.mccollum

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Too Many Requests)

قد يكون هذا هو السبب. في هذه الحالة، من المحتمل أن تكون قد تجاوزت الحد المسموح به.
قد تتحقق من علامة تبويب الشبكة في وحدة تحكم المطور، إذا كانت هناك المزيد من الطلبات، عندما تكون كتل الشريط الجانبي الأيمن ممكّنة.

[sandra.mccollum]

سؤال واحد إذا كان أي شخص يعرف:

(1) أنا مسؤول، مستوى الثقة 4، فلماذا لا يتجاوزني “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” لأي حد للمعدل؟

Available settings for global rate limits and throttling

Discourse ships with 3 different global rate limits that can be configured by site admins. Global per-ip rate limits These limits apply to every unique IP address that hits the Discourse application. (files that are served directly from the filesystem or the CDN are excluded) By default this rate limit is enabled, you may disable it or set it to a reporting mode. DISCOURSE_MAX_REQS_PER_IP_MODE : default block, this rate limit applies out of the box. (other options are warn, warn+block, and n…

حدود المعدل العالمية لكل عنوان IP
تنطبق هذه الحدود على كل عنوان IP فريد يضرب تطبيق Discourse. (يتم استبعاد الملفات التي يتم تقديمها مباشرة من نظام الملفات أو شبكة توصيل المحتوى)

بشكل افتراضي، يتم تمكين حد المعدل هذا، يمكنك تعطيله أو تعيينه إلى وضع الإبلاغ.

DISCOURSE_MAX_REQS_PER_IP_MODE: افتراضي حظر، ينطبق حد المعدل هذا بشكل افتراضي. (الخيارات الأخرى هي تحذير، تحذير + حظر، ولا شيء)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: عدد الطلبات لكل عنوان IP في الدقيقة (الافتراضي هو 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: عدد الطلبات لكل عنوان IP في 10 ثوانٍ (الافتراضي هو 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: عدد طلبات الأصول (الصور الرمزية/CSS) لكل عنوان IP في 10 ثوانٍ (الافتراضي هو 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: هل يجب تطبيق حد المعدل على عناوين IP الخاصة التي تصل إلى Discourse؟ الافتراضي هو خطأ.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: استخدم حدود المعدل لكل مستخدم مقابل حدود المعدل لكل عنوان IP للمستخدمين الذين لديهم مستوى الثقة هذا أو أعلى (الافتراضي 1)

لتعديل الحدود، أضف التغيير المطلوب إلى ملف app.yml الخاص بك في قسم البيئة.

قد أحاول:

DISCOURSE_MAX_REQS_PER_IP_MODE: warn
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 600
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 200
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 400
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: false
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: 2

لقد تحققت أيضًا من سجل وصول nginx، ويظهر عناوين IP مختلفة لمستخدمينا. (رأيت في موضوع سابق جدًا حيث كانت هذه مشكلة، كان الجميع يستخدمون نفس عنوان IP للوصول)

[sandra.mccollum]

حتى مع التغييرات الموضحة أعلاه وبعد إعادة بناء التطبيق، أرى تحذير حد المعدل في وحدة تحكم المتصفح إذا قمت بتمكين كتل الشريط الجانبي الأيمن.

كيف يمكنني طباعة أو تحديد القيمة الفعلية، على سبيل المثال: DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL

أيضًا، إذا قمت بتعطيل كتل الشريط الجانبي الأيمن، فلا أرى أي تحذيرات لحد المعدل في وحدة تحكم المتصفح إذا قمت بالانتقال عبر المواضيع بنفس المعدل الذي أقوم به مع تمكين كتل الشريط الجانبي الأيمن.

[thoka (Thomas Kalka)]

أقترح البحث في المناقشات السابقة حول تحديد المعدل.
لست خبيرًا في هذا الموضوع، ولكن حسب فهمي، يتم تطبيق تحديد المعدل على مرحلتين: أولاً، يقوم nginx بتحديد المعدل (دون معرفة مستويات الثقة)، ثم يقوم تطبيق rails بطبقة حماية أخرى.

إذا كنت ترغب في اختبار الفرضية القائلة بأنك تواجه حدود المعدل ضمن طبقة nginx، يمكنك التعليق على السطر التالي في ملف app.yml الخاص بك:

- templates/web.ratelimited.template.yml

[sandra.mccollum]

ليس لدي أي حدود لمعدل الطلبات محددة في nginx الذي أستخدمه كوكيل عكسي، وسأجرب ما تقترحه لمعرفة ما يفعله الحاوية.

أقوم بتحميل لوحة المتصدرين، وأعلى المنتجين، والأحداث في كتل الشريط الجانبي الأيمن.

سأبلغكم بالنتائج، شكرًا.

أراهن أنك على حق، فما هي القيم الجيدة ولكن الأكثر تساهلاً لهذه الإعدادات في /var/discourse/templates/web.ratelimited.template.yml؟ هل هو مجرد تجربة وخطأ؟

params:
reqs_per_second: 12
burst_per_second: 12
reqs_per_minute: 200
burst_per_minute: 100
conn_per_ip: 20

run:

• replace:
  filename: “/etc/nginx/conf.d/discourse.conf”
  from: /server.+{/
  to: |
  limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;
  limit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;
  limit_req_status 429;
  limit_req_zone $binary_remote_addr zone=connperip:10m;
  limit_conn_status 429;

لقد قمت بزيادتها إلى:

reqs_per_second: 18
burst_per_second: 18
reqs_per_minute: 400
burst_per_minute: 200
conn_per_ip: 20

لا يزال يظهر لي خطأ “429 Too Many Requests”.

لقد أزلت لوحة المتصدرين، ولا يزال الخطأ يظهر.

لقد أزلت كتل الشريط الجانبي الأيمن، ولم يعد هناك مشكلة مزعج جدًا!

ليس أنني لا أواجه هذه المشكلة مع الشريط الجانبي لأعلى المساهمين.

[thoka (Thomas Kalka)]

إذا كنت تعمل من عنوان IP ثابت، فيمكنك استبعاد عنوان IP الخاص بك من تحديد المعدل:\n\nhttps://meta.discourse.org/t/available-settings-for-global-rate-limits-and-throttling/78612/71\n\nللتجربة الأولى، سأتخطى تحديد المعدل تمامًا (فقط لا تستخدم web.ratelimited.template.yml)\n\n\n[quote="sandra.mccollum, post:11, topic:343964"]\nأراهن أنك على حق، فما هي القيم الجيدة ولكن الأكثر تساهلاً لهذه الإعدادات في /var/discourse/templates/web.ratelimited.template.yml؟ هل هي مجرد تجربة وخطأ؟\n[/quote]\n\nقد تجد مصدر الطلبات عن طريق تصفح سجلات nginx:\n\n ./launcher enter app\nless /var/log/nginx/access.log\n