البيئة: استضافة ذاتية لـ Discourse على AWS EC2، باستخدام صورة AMI لنظام Ubuntu 24.04. المضيف هو r7g.large مع 2x vCPUs و 16GB RAM. إصدار Discourse هو 3.6.0.beta1-dev (db974047e4) ويتم تحديثه بانتظام. إصدار WordPress هو 6.8.2، وإصدار المكون الإضافي wp-discourse هو 2.5.9. يتم توجيه كل من Wordpress و Discourse (“السحابة البرتقالية”) خلف Cloudflare.
إعدادات wp-discourse الحالية: أعرض تعليقات Discourse لجميع المواضيع، ولدي خيار “تحميل التعليقات باستخدام Ajax” محددًا. (يرغب كل من القراء وأصحاب موقع Wordpress في عرض التعليقات الجديدة بأسرع ما يمكن أسفل منشورات WP، لذلك بناءً على متطلبات المالكين، أفضل ترك “تحميل التعليقات باستخدام Ajax” ممكّنًا.)
ما أراه: بشكل عام، يعمل wp-discourse بشكل رائع. عندما يزور القارئ منشور WP، يطلب متصفحه /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX، حيث XXXXX هو معرف المنشور المتوقع، وتُحمّل التعليقات دون مشكلة. تظهر التعليقات الجديدة على جانب Wordpress في غضون ثوانٍ قليلة من نشرها في Discourse.
ومع ذلك، تصدر متصفحات الزوار أيضًا استدعاءً لنفس عنوان URI discourse-comments عند زيارتهم لأي عنوان wordpress على الموقع بأكمله. صفحة الموقع الرئيسية، أرشيفات التعليقات، صفحة “حول”، صفحة الاتصال، صفحات السيرة الذاتية للمؤلف، الصفحات الثابتة، صفحات البحث، كل شيء. كل هذه الطلبات هي لـ /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined، وأحصل على حوالي 20,000 منها في فترة 24 ساعة (تتوافق تقريبًا مع العدد الإجمالي للصفحات التي تم تقديمها).
لا أهتم كثيرًا، باستثناء أن خدمة هذا العدد الكبير من الطلبات الإضافية تسبب حملًا ملحوظًا على خادم WP الأصلي الخاص بي. إنه قابل للإدارة الآن، لكن هذا الموقع هو موقع للتنبؤ بالطقس في ساحل الخليج، وخلال أحداث الطقس (خاصة الأعاصير) يمكن أن يرتفع عدد المشاهدات اليومي من 20 ألفًا المعتاد إلى ما بين 1.5-2 مليون، والتعامل مع ملايين طلبات post_id=undefined في يوم واحد سيكون تحديًا.
الشيء الوحيد الذي يمكنني العثور عليه هنا في meta والذي يبدو أن له علاقة بهذه المشكلة هو هذا الموضوع من عام 2019، حيث كان الرد المقدم هو “إيقاف تحميل التعليقات باستخدام ajax”. كما ذكر أعلاه، نظرًا للمتطلبات التي أعمل بموجبها، أفضل عدم القيام بذلك.
إليك طلب undefined تمثيلي. تم إنشاء هذا الطلب عندما قمت بالوصول إلى الصفحة الرئيسية للموقع:
حل مؤقت: نظرًا لأن هذه الطلبات لا تبدو أنها تفعل أي شيء فعليًا، فقد قمت بتطبيق قاعدة جدار حماية تطبيقات الويب (WAF) في Cloudflare للرد عليها على مستوى CF باستجابة فارغة. لقد أزال هذا تمامًا آثار السلوك الإشكالي - لم أعد أرى طلبات undefined في خادمي الأصلي، ولا أهدر وحدة المعالجة المركزية في إنشاء استجابات.
السؤال: هل إرسال طلبات Ajax لـ discourse-comments?post_id=undefined لكل صفحة WP هو السلوك المقصود للمكون الإضافي wp-discourse؟ يبدو أنه قد يكون أكثر أمانًا (أو على الأقل أكثر تحديدًا) إرسال هذه الطلبات فقط عند تحميل منشور WP فعليًا (أو صفحة أيضًا، إذا كانت الصفحات ممكّنة في خيارات wp-discourse).
كما قلت، لدي حل مؤقت مطبق يبدو أنه يقوم بالمهمة ويزيل الحمل الإضافي لمعالجة عشرات الآلاف من الطلبات الزائفة، لذلك أنا مستقر وفي وضع جيد. ولكن سيكون من الجيد معرفة ما إذا كان السلوك الذي أراه هو حسب التصميم.
