لقد واجهنا مشكلة متكررة في منتدى Discourse الخاص بنا لفترة من الوقت، وقد تمكنا أخيرًا من تحديد سببها بدقة وإعادة إنتاجها بشكل موثوق.
إليك خطوات إعادة إنتاج المشكلة:
وجود موضوع يحتوي على آلاف الردود.
وضع إشارة مرجعية (Bookmark) لمنشور ضمن ذلك الموضوع.
فتح الموضوع.
يصبح تحميل الموضوع الآن يستغرق وقتًا طويلاً. وفي بعض الحالات، ينتهي الأمر بانتهاء مهلة الطلب (Timeout) وظهور خطأ من Nginx بدلاً من ذلك (502 Bad Gateway).
فيما يلي بعض أوقات التحميل التقريبية من منتدى لدينا:
لموضوع يحتوي على حوالي 1,000 رد، فإن الوقت الإضافي للتحميل بعد إنشاء إشارة مرجعية هو بضع ثوانٍ. الأمر ملحوظ لكنه لا يشكل مشكلة كبيرة.
لموضوع يحتوي على حوالي 4,000 رد، يستغرق التحميل عادةً من 20 إلى 30 ثانية، وأحيانًا ينتهي بانتهاء المهلة بدلاً من تحميل الصفحة بنجاح.
لموضوع يحتوي على أكثر من 9,000 رد، ينتهي الأمر بانتهاء المهلة في معظم الأحيان. وفي بعض الحالات يتم التحميل، لكن فقط بعد أكثر من 30 ثانية.
لاحظ أن هذه المواضيع تُحمّل دون أي مشكلة إذا لم تكن هناك إشارات مرجعية فيها. وتحدث المشكلة فقط للمستخدمين الذين لديهم إشارات مرجعية في موضوع معين، وبمجرد إزالة الإشارة المرجعية، يعود تحميل الموضوع إلى طبيعته مرة أخرى.
إذا لم يكن ذلك إزعاجًا كبيرًا، هل يمكنك تجربة تعيين تذكير مؤقت عند إنشاء الإشارة المرجعية في الخطوة 2 من وصف إعادة الإنتاج، وملاحظة ما إذا كان هناك أي تغيير؟ هذا ما جعل الأمر قابلاً لإعادة الإنتاج بالنسبة لي في النهاية (تحديدًا تعيين تذكير لـ “الاثنين” في حالتي).
هذا التسبب في أن طلب .json الخاص بالإشارة المرجعية للمشاركات بدأ يعيد رمز 302 بعد محاولة لمدة 30 ثانية، كما هو موضح في الصورة أدناه. (يحدث عند النقر على رابط الإشارة المرجعية في قائمة ملفي الشخصي).
بالصدفة، لاحظت أيضًا أن عمليات البحث بدأت تظهر سلوكًا مشابهًا، على الرغم من أنها تبطئ بشكل هائل فقط عند البحث عن أي شيء في أي نموذج فرعي، بما في ذلك تلك التي لا تحتوي على أي مشاركات مؤشرة على الإطلاق:
[تم حذف صورة استعلامات البحث البطيئة من أدوات مطوري Chromium حيث تم السماح بتضمين واحد فقط]
من تجارب أخرى، يبدو لي أن الأمر يشبه نوعًا ما مشكلة SQL N+1، لكنني لست على دراية كافية بأكواد Discourse ولا بلغة Ruby نفسها لأعرف ما إذا كان نموذج JSON دوري أو ما شابه ذلك سيظهر بنفس الطريقة.
