شكرًا لك. لقد أنقذتني على الأرجح من ساعات طويلة من التصحيح والتجربة والخطأ.
هذا الاختلاف في السلوك قد قاده إلى الاستنتاج بأن هذا ارتباط تطبيقي ناتج عن مشكلة في الواجهة الأمامية “تسبب في تعطل” التطبيق (كون الواجهة الأمامية ليست مجال خبرتي، على عكس الواجهة الخلفية)، والعمليات الجارية من خلال النشر وبقاء الأشخاص على موضوع ما بانتظار “تحديثه ذاتيًا” بعشرات الرسائل في دقيقة واحدة.
لخلاصة هذه الجملة الطويلة: هل استنتاجك هو أن “الاختناق” الناتج عن النقاش الفوري السريع هو مشكلة في الواجهة الأمامية؟
لم أذهب بعيدًا في تحليلنا، لكنني لاحظت أن حمل المعالج لم يكن قريبًا من الحد الأقصى، بل كان حوالي 25% فقط. على مر السنين، وصلنا إلى حمل 100% للمعالج مرات عديدة، لكن هذا لم يكن الحال في الحادث الأخير يوم السبت الماضي. كان لدينا حوالي 150 مستخدمًا متزامنًا فقط.
ما الذي دفعني للاشتباه في الواجهة الخلفية هو أننا ندير هذه غرف الدردشة للألعاب منذ سنوات، ولم أرَ هذا “الاختناق” من قبل. على مر السنين، نما قاعدة البيانات، وأصبح لدينا الآن أكثر من 800,000 منشور.
متى رأيت هذا لأول مرة؟ هل يمكن أن يكون هذا تراجعًا مع التحديث الرئيسي الأخير؟ كان موقعنا وأداؤه جيدًا في الربيع، ولم نكن قد نمانا كثيرًا خلال الصيف.
لدينا الآن مهمة معلقة في قائمة الانتظار لتحسين الأداء في الحالات التي يتابع فيها 1000 شخص نفس الموضوع ويقوم شخص واحد بنشر رسالة.
كما هو مُصمم اليوم، نرسل إشعارًا لجميع الـ 1000 شخص: “مرحبًا، هناك منشور جديد لهذا الموضوع”، ثم يتجه الجميع (معظمهم في نفس الوقت) إلى الخادم ليطرحوا السؤال: “مهلاً، ما هو هذا الموضوع الجديد الذي تطلبونه؟”
سنقوم بدراسة وضع حد أدنى للتحكم في معدل الطلبات بطريقة أنظف حتى لا تضغط التطبيقات على الخادم، ولكن هناك العديد من التحسينات التي يمكننا إجراؤها لهذه الحالة الاستثنائية.
أخبار رائعة بأن هذا الموضوع تحت رصانتكم. هل يمكنكم التأكيد ما إذا كانت هناك انتكاسة منذ الربيع الماضي؟
تسعى دوري الهوكي المحلي لدينا إلى بدء المباريات في الأول من أكتوبر. وهذا يعني أن موقعنا يمكنه توفير طفرات حركة مرور مباشرة بشكل أسبوعي، في حال احتجت/أردت دراسة السلوك كما يحدث في بيئة حقيقية (غير محاكاة).
راسلنا بالرسائل الخاصة إذا كنتم مهتمين. نحن مستعدون للدعم.
من وجهة نظر تجربة المستخدم، يجب أن يعرف المستخدم النهائي بطريقة ما أن النقاش نشط، حتى عندما يبدأ النظام في التعثر. قد يمنع ذلك عمليات تحديث المتصفح غير الضرورية.
انتهت المباراة الأولى للتو ولدينا بالتأكيد مشكلة لم نواجهها في مارس. السبب لا يزال مجهولاً.
محادثة اللعبة تتعطل في الواجهة الأمامية، بينما يجب أن يكون حمل الخادم أقل بكثير من 100٪.
لاحظ أحد مستخدمينا عددًا من استجابات الخادم 429 أثناء حالات التعطل، لكن لا يمكنني القول ما إذا كان هذا “طبيعيًا” لأننا لم نقم بمثل هذا الفحص من قبل أثناء المباريات.
لقد رأيت واحدة من تلك أثناء التحقيق في خطأ ‘500’ غير ذي صلة تمامًا
لم يكن الخادم مشغولًا على الإطلاق، لكنني كنت أتعامل مع إعدادات nginx الأمامية (http2)
بالفعل. كانت هناك حوالي 900 رد فعل سلبي خلال بضع ساعات. لدى @ljpp أرقام أكثر دقة حول عدد المستخدمين، لكننا نتحدث عن مئات المستخدمين يتصفحون الموضوع في أي وقت أثناء المباراة.
ومن الغريب أن هذا لا يؤثر على كل مستخدم. أنا، على سبيل المثال، لم أعثر على أي مشاكل على أي جهاز. لكن التقارير تشير إلى أن المشكلة واسعة النطاق.
ليس من السهل ملاحظة ذلك، خاصة إذا لم تكن تنتبه عن كثب.
أولاً، هناك توقف لمدة 30-60 ثانية دون أي ردود. لا يبدو أن هناك أي شيء “خاطئ”، بل إن كل شيء هادئ فقط. يمكنك حتى كتابة منشورك الخاص. ثم فجأة تصلك عشرات الرسائل في لحظة، وتدرك أنك كنت متأخرًا. لقد لاحظت هذه الظاهرة على Safari في iOS وعلى Chrome في Android.
دردشات ألعابنا في الوقت الفعلي نشطة، لكنها ليست حالات متطرفة. أمس، تلقينا 972 رسالة خلال فترة زمنية تقارب 3 ساعات.
ستعقد دردشة المباراة التالية اليوم الساعة 14:00 بتوقيت UTC. ونظرًا للوباء، أتوقع أرقامًا مماثلة، على الرغم من أن المباراة ستقام على أرضنا.
أليس هدفك هو فرض حالة استخدام الدردشة على منصة المنتدى؟
لماذا لا تدمج بدلاً من ذلك خدمة دردشة مثل Mattermost أو Discord في واجهة موقع Discourse الخاص بك، وتستخدم هذه الوسيلة لتغطية المناقشات داخل اللعبة؟
يمكنك إيجاد طريقة أخرى لتغطية اللعبة في موضوع منتدى، مثل المناقشات قبل أو بعد المباراة، حيث قد يكون حمل الاستخدام أقل تطلبًا، ولكن قد يحتوي على معلومات موجزة مفيدة قد يرغب العديد من المستخدمين في استرجاعها لاحقًا.
أيضًا، لا أرى فائدة في تخزين حجم كبير من الدردشة العفوية على المنتدى. هل سيقوم أي شخص بقراءتها مرة أخرى؟ هل هي مفيدة؟
حسناً، هو يستخدم كلمة “دردشة” لهذا الغرض، لكن إعدادات Discourse لديه لا تستطيع التعامل مع “972 منشوراً خلال حوالي 3 ساعات” في موضوع واحد وفقاً للمستخدم… وأعتقد شخصياً أنه يجب أن تستطيع ذلك، فحتى نظام phpBB البسيط يمكنه التعامل مع عدد أكبر بمراحل من المنشورات خلال 3 ساعات من هذا.
إذن منشور واحد كل 10 ثوانٍ؟ بحد ذاته لا يبدو ذلك غير معقول. لكنك بعد ذلك تجعل الموضوع يحتوي على 1000 منشور، ويشترك فيه مئات المستخدمين، وعلاوة على ذلك تحصل على طفرات في عدد المنشورات. أستطيع أن أرى التحدي!
لكن ما هو السبب الحقيقي/عنق الزجاجة هنا؟ هل هو عدد المستخدمين المشاركين، أم منشور واحد كل 10 ثوانٍ، أم عرض المحتوى المتغير لعدد (كبير جدًا) من المستخدمين المجهولين/غير المجهولين، أم عدد الاتصالات المطلوبة لخدمة عدد كبير من المستخدمين المسجلين؟
هل سيواجه نفس المشكلة إذا كان هناك مستخدمان فقط ينتجان نفس عدد المنشورات في موضوع معين خلال نفس الإطار الزمني؟
حتى مع وجود 972 مستخدمًا مسجلًا فقط يقومون بنشر منشور واحد في ذلك الموضوع، ألا يستطيع ديسكورد التعامل مع هذا؟ وإذا كان الأمر كذلك، فلماذا؟ هل ديسكورد هو الخيار الصحيح فقط للمجتمعات الصغيرة جدًا ذات العدد المنخفض من المستخدمين المسجلين المتزامنين؟
أنا أتساءل فقط لأننا لدينا بالفعل ما يصل إلى 400 مستخدم مسجل متزامن في بعض الأوقات ينتجون ما يصل إلى 3000 منشور يوميًا… وحتى الآن لا توجد مشاكل.
بالتأكيد، نحن نستخدم حاليًا 8 جيجابايت من الذاكرة و4 وحدات معالجة مركزية افتراضية من DigitalOcean، ولا نواجه أي مشاكل في الوقت الراهن. لذا، إذا كان حل هذه المشكلة هو ببساطة زيادة الموارد (الذاكرة العشوائية والمعالج)، فهذا مقبول بالنسبة لي. عند الذروة منذ إعادة التشغيل مع Discourse، كان لدينا حوالي 2000 زائر متزامن في منشور واحد انتشر بشكل واسع، وكان الحمل أعلى قليلاً من 1، بينما كانت نسبة استخدام المعالج بين 60-70%. أما في المتوسط مع حوالي 200-250 مستخدم متزامن مسجلين الدخول، فإن نسبة استخدام المعالج منخفضة حاليًا وتتراوح بين 15-20%.
يمكنك تقديم هذا الحجة، لكنني لا أحب فكرة تجزئة المحادثات بين منصتين. في الواقع، تعتبر اللحظية إحدى الميزات الحاسمة في Discourse التي يقدرها المستخدمون النهائيون. محادثات وقت لعبنا تحظى بنجاح كبير وهي جزء مهم من ثقافة المجتمع.
لاحظ أننا ندير هذه المحادثات منذ أربع سنوات، وهذه مشكلة جديدة نواجهها الآن. إذًا، مئات الألعاب سارت بسلاسة دون “فرض” أي شيء.
كان لأحد أعضائنا المتعلمين نظرية — هل من الممكن أن نصل إلى الحدود العالمية لـ Discourse، وربما يكون لـ CloudFlare تأثير؟
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : عدد الطلبات لكل عنوان IP في الدقيقة (الافتراضي هو 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : عدد الطلبات لكل عنوان IP كل 10 ثوانٍ (الافتراضي هو 50)
المباراة القادمة بعد ساعة واحدة، وسنختبر ذلك مع تعطيل ذاكرة التخزين المؤقت لـ CF.
لاحظ أننا نستخدم CloudFlare منذ أربع سنوات أيضًا، رغم أنه لا يُنصح به عمومًا هنا. لم نواجه سوى مشكلة أو مشكلتين على طول الطريق، كان Brotli واحدة منها، وقالب غير محدث أخرى.
