لقد تلقيت تقارير من أعضائي حول رسالة تحذير هذه. لا تظهر بكثرة، لكنها تُلاحظ. هل يمكنني افتراض أنه لا يوجد ما يجب فعله هنا، وأن الأمر ليس خطيرًا كما يبدو؟ إن عبارة “حمل شديد” تبدو وكأنها مشكلة كبيرة. لكنها تختفي تقريبًا على الفور ويعود البحث للعمل مرة أخرى.
أقدر أي توجيهات تتعلق بخطوات استكشاف الأخطاء وإصلاحها. شكرًا لك! 
الموقع تحت حمل شديد، تم تعطيل البحث، حاول مرة أخرى لاحقًا
لست متأكداً تماماً من أن الأمر يتطلب استكشاف الأخطاء وإصلاحها. لكن ربما يمكن التعامل معه بطريقة مختلفة؟
https://review.discourse.org/t/feature-when-under-extreme-load-disable-search/4538/3
يجب أن تكون قلقًا، أنصحك بمراجعة تقرير الزحف الخاص بك في لوحة تحكم المسؤول.
سيتم تفعيل ذلك عندما تكون طلبات الويب أسرع مما يمكن لخادمك معالجته.
على سبيل المثال، إذا كان لديك 4 وحدات معالجة (unicorns) وتحتاج في المتوسط إلى 200 مللي ثانية لمعالجة طلب بشكل كامل، فإن سعتك هي 20 طلبًا في الثانية.
إذا حصلت فجأة على 40 طلبًا في الثانية، فستنتظر الطلبات الإضافية في طابور، وسيظهر ذلك الرسالة. أيضًا، لا يمكنك ببساطة زيادة عدد وحدات المعالجة (unicorns) بشكل عشوائي، لأن عملية الرد الكامل على طلب ويب تتضمن العديد من الأجزاء المتحركة التي يجب تقييمها بعناية.
اكتسب Discourse مؤخرًا العديد من ميزات التدهور التدريجي بينما نعمل على التوسع في البنية التحتية والتعامل مع مستويات هائلة من حركة المرور لأضخم نسخ Discourse على الإنترنت.
يبدو أننا سجلنا زيادة في مشاهدات صفحات عناكب الويب في الأيام الأخيرة. لكنني لست متأكداً مما إذا كان هناك أي إجراء يمكنني اتخاذه أو يجب عليّ اتخاذه حيال ذلك. شخصياً، لا بأس بي في إرسال إشعار للأعضاء بين الحين والآخر عندما يكون الخادم تحت حمل أعلى من المعتاد، مما يمنع البحث مؤقتاً. ولكن ربما يمكن تخفيف رسائل “الحمل الشديد” قليلاً، لتصبح “الخادم مشغول”.
قم بحظر وكيل المستخدم (user-agent) الخاص بمحرك الزحف الضال في إعدادات الموقع. هناك العديد من محركات الزحف السيئة جدًا على الإنترنت هذه الأيام.
حسناً، من غير المرجح أن تسبب 1800 مشاهدة صفحة في 24 ساعة من قبل برنامج زحف عبئاً إضافياً كبيراً على خادمك. قد يكون من المفيد فتح سجل الوصول ومراقبة الطلبات الواردة عند حدوث ذلك، فقد يشير ذلك إلى المشكلة الحقيقية. قد يكون الأمر محاولة لاختراقك، أو إغراق واجهة برمجة التطبيقات الخاصة بك بالطلبات.
لقد تلقيت للتو تقريرًا عن إشعار آخر ذو مظهر مشابه. نحن نقوم بجلسة أسئلة وأجوبة (AMA) ولدينا عدد أكبر من المعتاد من الأشخاص الذين يقرأون وينشرون في المنتدى، لكنني لست مقتنعًا بأن هذا يمثل حملًا شديدًا. ربما يكون أحد الإضافات مثل Discourse Who's Online هو السبب في زيادة الحمل؟
شكرًا لك! سأقوم بالتحقيق في هذا الآن.
هل هناك طريقة لتعطيل هذه الميزات في إعدادات المسؤول والسماح للأشخاص بالانتظار فقط إذا كان الموقع بطيئًا؟ أعتقد أن موقعنا لا يزال غير مزدحم بشكل خاص.
إذا تدهور الأداء إلى حد حدوث مهلة زمنية، فلن يبدو بطيئًا، بل سيبدو وكأنه معطّل.
إن تجاهل هذه التحذيرات ليس فكرة جيدة على الإطلاق!
أنا أتلقى إشعارات حمل شديد بشكل متكرر مؤخرًا.
لدي منتدى رياضي، وعادة ما يحدث ذلك عندما يقوم أشخاص بالتعليق على موضوع واحد يتعلق بمباراة معينة في نفس الوقت. هل هناك دليل أو مساعدة حول ما يمكنني التحقق منه لفحص السجلات أو الخادم لمعرفة ما إذا كان يعمل بكفاءة؟ لم يكن هذا مشكلة حتى الأسابيع القليلة الماضية.
هل تعتقد أننا قد عانينا من تراجع في أداء نشر المستخدمين المسجلين الدخول @sam؟
أرى بالتأكيد مشكلة N+1 في الميتا يجب إصلاحها على وجه السرعة.
سأسجل بعض العناصر لحل هذه المسألة. مع ذلك، بمجرد أن يصبح الموقع مثقلاً، يتمتع المشرفون بالقدرة على تعديل أمرين:
يمكنك تزويد المثيل بموارد أكثر (ذاكرة أكبر لـ PG أو عمال أكثر لـ Unicorn).
يمكنك ضبط عتبة المستخدم المجهول وفقاً للمعايير التالية:
DISCOURSE_FORCE_ANONYMOUS_MIN_QUEUE_SECONDS و DISCOURSE_FORCE_ANONYMOUS_MIN_PER_10_SECONDS
لقد قمت بإصلاح مشكلة N+1 واحدة في إضافة discourse-voting هنا:
سأرى ما إذا كانت هناك أي مشاكل أخرى تظهر.
وجدت N+2 أخرى هنا:
أبحث عما إذا كان سيظهر أي شيء آخر.
س: ما هو “N+1”؟ على الرغم من أنني مطور (Java)، إلا أنني أعتقد أنني لم أصادف هذا المصطلح من قبل.
إليك مقالة (متعلقة بـ Java إلى حد ما) تشرح هذه المشكلة:
