لقد حققنا للتو تحسينًا كبيرًا في الأداء للمواقع التي تتضمن نشرًا نشطًا وعددًا كبيرًا من المستخدمين، وهو ما من شأنه أن يساعد موقعك بشكل كبير.
جيد جداً، سنلقي نظرة ونختبر هذا محتملًا.
حسناً، كل لعبة هي حالة فريدة. وفي ظل ظروف كوفيد الحالية (ملعب فارغ) وجدول مباريات شبه عشوائي، يصعب التنبؤ بسلوك الجمهور أو مقارنته بالبيانات التاريخية.
بناءً على هذه المباراة الواحدة، لا يمكنني القول إن هذا التغيير جلب لنا تحسناً ملحوظاً.
كانت الفترة الأولى هادئة وجيدة، لكن الأحداث التي وقعت في الفترة الثانية تسببت في ارتفاع مفاجئ في عدد الرسائل وزيادة في عدد المتطفلين (lurkers). وقد أفاد حوالي 60% من مستخدمينا بتجربة تجمّد (freezes).
في إعداد الخادم المزدوج، يُعد خادم web_only هو الوحيد الذي يُبلغ عن استهلاك مرتفع لوحدة المعالجة المركزية (CPU) ومتوسط الحمل.
لم يتم تفعيل وضع “الحمولة القصوى / القراءة فقط”، وهو أمر إيجابي لأنه يسبّب أسوأ تجربة مستخدم. بشكل عام، تعلم الجمهور بسرعة زيارة الصفحة الرئيسية والعودة لاستئناف النقاش، مما يولّد حمولة إضافية على الخادم. لو أمكن إبلاغ المستخدم النهائي بطريقة ما بأنه يتم تقييد سرعته، لكان أكثر ميلاً للانتظار دقيقة فعلياً.
تقرير تقدم من المحادثات الخاصة: تم تحسين التجربة عن طريق ضبط DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS على 4، ونخطط لإجراء بعض التغييرات الأساسية لتحسين سلوك تحديد معدل نقل الرسائل في Message Bus.
نظرًا لأننا نواجه بعض أوجه التشابه مع حالة @ljpp، وإن كان ذلك بدرجة أقل بكثير (تقتصر تقريبًا على بضع دقائق حول وقت انتهاء المباريات)، أود أن أعرف ما إذا كان هناك أي تعديلات يمكن إجراؤها على العتبة التي يبدأ عندها ظهور رسالة الحمل المرتفع، ويبدأ المستخدمون في «طرد» من الموضوع… لأن الأمر يتعلق دائمًا بموضوع واحد فقط، وهو موضوع المباراة.
إلى جانب ذلك، هناك رسالة خطأ 502 (رسالة نginx بحتة) التي نواجهها بشكل أقل تكرارًا في نفس السياق. أشك في أن هناك بعض الإعدادات في nginx قد تستفيد من بعض الضبط، وأنا أعلم أن هذا ليس من مهامكم، لكنني مستعد تمامًا لاستقبال أي اقتراحات جيدة 
.
يرجى التوضيح: هل تواجهون تجمّدًا (عدم تحديث الموضوع مع المنشورات الجديدة) أم أنكم تتلقّون رسائل خطأ تشير إلى “حمل مفرط”؟
هناك بعض التحسينات في هذا الموضوع تساعد في التخفيف من مشكلة التجمّد، لكنها في الوقت نفسه تزيد من حمل النظام، مما يجعل احتمالية وقوع سيناريوهات “الحمل المفرط” أكثر.
نواجه أحيانًا تجميدًا للمواضيع في تلك الحالات التي أبلغت عنها، ولكن عندما يحدث ذلك، يُظهر النظام أيضًا تحذيرات بشأن الحمل الشديد. لذا لا يمكنني تحديد ما هو السبب بالضبط.
لا يزعجنا الحمل الشديد طالما أنه لا يطرد المستخدمين من المواضيع أو يقطع تحديث المنشورات الجديدة. في الواقع، في مثل هذه الحالة، نفضل أن يتم تحميل المحتوى ببطء (حيث يمكن أن تدور دائرة التحميل لمدة 15 ثانية لكل مستخدم للقراءة أو النشر)، ونفضل ذلك على التجميد أو طرد المستخدمين.
أوافقك الرأي. تجربة المستخدم في ظل الحمولة القصوى مربكة للمستخدم النهائي.
- كم عدد المستخدمين المتزامنين لديك؟
- ما نوع الأجهزة المستخدمة؟
- رابط إحصائيات المنتدى الخاص بك؟
بما أننا انتقلنا الآن إلى منصة CDCK SaaS، يمكنني فقط مراقبة هذا الأمر من منظور تجربة المستخدم (UX).
شهدنا بعض الحماس الجيد في الألعاب خلال الأسابيع القليلة الماضية. لقد اختفت “التجمدات” إلى حد كبير مع تغيير المنصة، لكن لا تزال هناك تذبذبات في طريقة تحديث الموضوع، مما قد يظل محيرًا لبعض المستخدمين. ومع ذلك، توقف الجمهور (بنسبة 90%) في الغالب عن الشكوى وركز على الألعاب، وهو ما يُعد مؤشرًا إيجابيًا.
ومع ذلك، هناك سيناريو يمكنني تكراره بثقة عالية (مرة أخرى 90%). تواجه المنصة أحيانًا مشكلات في استئناف الجلسة عندما يكون موضوع اللعبة في علامة تبويب خلفية (على نظام أندرويد) أو تحت شاشة مقفلة. عندما أعود إلى الموضوع النشط، عادةً بسبب حدث مثير للاهتمام في اللعبة، لا يتم تحديث عرض الموضوع في بعض الأحيان. يمكنني رؤية صور رمزية للمستخدمين تومض في أسفل الموضوع، لكن لا تظهر أي منشورات. يتطلب الأمر تحديث المتصفح للتعافي بالكامل.
نمط التكرار ليس الأسهل، حيث تحتاج إلى:
- موضوع نشط
- بعض الإجراءات الجيدة في اللعبة → مزيد من الحماس للموضوع
- إبقاء الموضوع تحت شاشة مقفلة أو في علامة تبويب خلفية للمتصفح.
نحن نعاني من ذلك أيضًا.
الأمر الآخر هو أنه عند الانتقال إلى أول منشور غير مقروء، قد يتكرر هذا السلوك عدة مرات (الانتقال إلى نفس “المنشور غير المقروء” عدة مرات، على الرغم من أنه كان من المفترض أن يتغير موضع أول منشور غير مقروء في كل مرة).
للتوضيح:
- أنتقل إلى أول منشور غير مقروء
- أقوم بالتمرير وأقرأ 100 منشور غير مقروء
- ثم أذهب إلى موضوع آخر أو الصفحة الرئيسية…
- بعد دقيقة أو نحو ذلك، يكون هناك حوالي 30 منشورًا جديدًا غير مقروء، لكن عند النقر على الأيقونة، يتم إعادتي مرة أخرى إلى الموضع في الخطوة 1 (أي 130 منشورًا للخلف وليس فقط الـ 30 المنشورات الجديدة غير المقروءة).
ولكن، مرة أخرى، يحدث هذا فقط في المواضيع شديدة الازدحام خلال بضع دقائق في ذروة النشاط القصوى حيث يقوم جميع المستخدمين بالنشر والتحديث في نفس الموضوع وفي نفس الوقت. الأمر مزعج بعض الشيء لكنه ليس عائقًا حاسمًا حتى الآن.
أعتبر ذلك نجاحًا.
هل يمكنك تقديم مثال تكرار هنا على ميتا؟ ربما لا، لأن ذلك يتطلب عددًا كبيرًا من المستخدمين النشطين في وضع الخمول في نفس الموضوع في نفس الوقت.
فكرتي الحالية هي أننا يجب أن نبني ميزة دردشة مباشرة وننشئها في اللحظة المناسبة، عندما يكون لديك…
-
عدد كبير من المستخدمين
-
في نفس الموضوع
-
في نفس الوقت
-
حينها، و فقط حينها، ننشئ طبقة نافذة دردشة مباشرة ونشجع المستخدمين بقوة على استخدامها بدلاً من الردود، وربما حتى نعطّل القدرة على الرد على الموضوع مع:
مرحبًا، يبدو أن ما كنت تريد حقًا هو غرفة دردشة.. ها هي، استمتع! 
نعم، أعرف ما تقصده، لكن الأمر محدود بتلك المناسبات فقط، لذا أعتقد أنه لا يستحق الجهد. عادةً ما نلعب مباريات من هذا النوع مرة إلى مرتين في الأسبوع، وغالبًا ما يحدث ذلك في الدقائق الخمس الأولى بعد انتهاء المباراة. لكنني فكرت بالفعل في الأمر عدة مرات (سيكون رائعًا وجود وظيفة دردشة مؤقتة أو وسيلة للتبديل خلال الـ 90 دقيقة لمباراة كرة القدم).
مع ذلك، سأحاول تكرار ذلك يومًا ما عن طريق تسجيل الشاشة لفترة من الوقت.
تظهر مثيلتنا بعض أخطاء 429 مع بدء مباريات التصفيات. ينبغي على @staff أن يتمكنوا من رؤية بعضها في سجلات الـ 3.5 ساعات الأخيرة، ويُتوقع ظهور المزيد عند تسجيل الهدف الحاسم (اللعبة تنتقل إلى الشوط الإضافي الثاني بينما أكتب هذا).
على أي حال، إذا كنتم لا تزالون تسجلون وتتبعون هذه المشكلة، فإن الفرص المتبقية قليلة جدًا، حيث تقترب النهائيات وما يليها من موسم خارجي.
أردت فقط إضافة اسمي إلى هذا الموضوع حتى أتمكن من متابعته. نحن منتدى جمباز جديد. واجهنا ما سبق بالإضافة إلى “التجمّد” الليلة الماضية خلال تجارب الأولمبياد الأمريكية. إليك الموضوع…
https://gymnaverse.com/t/us-wag-olympic-trials-night-2-live-discussion/1092
كان لدينا 4 يونيكورن الليلة الماضية.
قمنا بتغيير حجم الخادم إلى 4 وحدات معالجة مركزية من إنتل وذاكرة 8 جيجابايت في Digital Ocean وقمنا بما يلي…
unicorn_workers: 8
db_shared_buffers: “2GB”
نتوقع حركة مرور أعلى بكثير خلال الألعاب الأولمبية. ما الذي يمكننا فعله لتحسين أداء الخادم لحركة مرور تشبه “الدردشة” أثناء المنافسة؟
إذا كان لديك مئات المستخدمين في موضوع واحد باستخدام Discourse كدردشة و كان الحدث محدود الوقت، فإنني أقترح زيادة الخادم مؤقتًا قليلاً.
القطرة الكبيرة من Premium AMD في Digital Ocean لمدة 16 يومًا من الألعاب الأولمبية كلفت 54.85 دولارًا، ويجب أن تكون كافية تمامًا لمجتمع بحجمك.
ليس لدي هذه الأسطر في ملف app.yml الخاص بي. هل عليّ إضافتها ببساطة؟
نعم. أضفها في قسم env.
إذا كان هذا لا يزال قيد اهتمام الفريق، فإن إقلاعنا الليلة الساعة 18:30 (توقيت شرق أوروبا +3) وسيتكرر غدًا في نفس الوقت.
هناك توقع كبير بعد موسمين دمرهما فيروس كورونا، لذا أتوقع ارتفاعًا كبيرًا في حركة المرور على موقع tappara.co
@ljpp
ما هو وضعك الحالي؟ هل ساعدك Redis 6؟
نحن الآن على CDCK SaaS، وهو ما دفعنا لإبلاغ الموظفين مسبقًا. نحن نوع من منصة الاختبار في هذا الشأن.