بسبب الحمل الشديد، يتم عرض هذا مؤقتًا للجميع كما يراه المستخدم غير المسجل.
أدير موقعًا إلكترونيًا يضم خيوطًا مباشرة أثناء مباريات كرة السلة، وقد واجهت مشكلات في ازدحام الخادم وعرض هذه الرسالة أثناء المباريات (أوقات الذروة).
هل توجد طريقة لتحديد أفضل السبل لمعالجة هذه المشكلة؟ هل الأمر يتعلق بسرعة التخزين، أم الذاكرة، أم وحدة المعالجة المركزية؟ هل هناك شيء يمكنني فعله غير ترقية خادمي؟ وإذا قمت بذلك خلال هذه الأوقات، فما الذي يجب ترقيته؟
هل يمكن تقليل عدد المستخدمين في المنتدى؟ والأفضل من ذلك أن يتم توزيع استخدامهم بدلاً من أن يحدث جميعه أثناء اللعبة.
لكن لا شيء من ذلك مفيد. بما أنك تعرف مواعيد الألعاب، فيمكنك تعزيز خادمك فقط أثناء اللعبة، أو تشغيل خوادم متعددة أثناء اللعبة خلف موزع أحمال.
تحتاج إلى المزيد من أنوية المعالج (CPU) الأسرع وذاكرة وصول عشوائي (RAM) أكبر، حتى تتمكن من زيادة عدد عمليات الويب (Unicorn Workers) للتعامل مع ذروة حركة المرور.
إنها منطقة يعمل عليها @sam بنشاط. يبدو أن إصدارات Discourse الأحدث قد تراجعت في هذا المجال من حيث الأداء.
ومع ذلك، فإن الحل الحقيقي هو استخدام أداة دردشة مباشرة إذا كنت بحاجة إلى تفاعلات فورية في الوقت الحقيقي لمئات الأشخاص في نفس الوقت، رغم أنني لا أزال أشكك في كيفية وفائدة الدردشة عندما تتحرك بسرعة كبيرة لدرجة أن لا أحد يمكنه حقًا رؤية أي شيء، مثل بث Twitch وYouTube. 
يصف هذا الموضوع المشكلة بشكل جيد للغاية.
كانت هذه تجربتي مع منتدى كرة قدم أثناء المباراة قبل أن تبدأ المشاكل:
Digital Ocean
معالج واحد وذاكرة 1 جيجابايت = 30-40 مستخدمًا في وضع الدردشة
معالجان وذاكرة 2 جيجابايت = 70-80 مستخدمًا في وضع الدردشة
4 معالجات وذاكرة 8 جيجابايت = مناسب لـ 120 مستخدمًا و1000 منشور خلال ساعتين. لم نصل إلى الحد الأقصى.
مع Hetzner (موقع النسخ الاحتياطي)
كانت تجربتي كالتالي:
3 معالجات (رقم CPX 21 من AMD) وذاكرة 4 جيجابايت = صعوبة مع 20 مستخدمًا
معالجان (Intel) وذاكرة 8 جيجابايت = لا توجد مشكلة مع 20 مستخدمًا.
لم أتمكن من اختبار ذلك مع عدد أكبر من المستخدمين.
النقطة الأساسية هي تحسين المعالج والذاكرة العشوائية (RAM). وأيضًا تعديل ملف app.yml.
أضف المزيد من الـ unicorns هنا، وعدّل أيضًا db_shared_buffers.
في منتديات الرياضة، تصبح أقرب إلى تحديثات نصية مباشرة للمباريات. لا يتواصل الناس كثيرًا عبر الدردشة (على الرغم من حدوث ذلك إلى حد ما، خاصة في وقت الاستراحة)، بل يحصلون بدلاً من ذلك على تعليق نصي مباشر من مشجعين آخرين.
كثير من الناس يسجلون الدخول إلى المنتدى فقط لقراءة النص المباشر. رؤية آراء وأفكار الأحداث الرئيسية للمباراة من قبل أشخاص رئيسيين. تتراوح من ردود فعل مضحكة إلى تحليلات جادة.
إذا فاتتك المباراة، يسجل الناس الدخول ببساطة لقراءة التعليق الحدث تلو الحدث. إنه رائع للأشخاص في العمل 
وهو أكثر شخصية/تحيزًا من التعليق النصي من الصحف أو القنوات التلفزيونية.
هذا صحيح. سيقوم discourse-setup بذلك إذا تم تشغيله على الخادم المُحدَّث.
أفهمك تمامًا، فهذا أمر نبحث فيه عن كثب أنا و@sam و@eviltrout.. فقد تكرر مؤخرًا بشكل ملحوظ سيناريو “مئات المستخدمين المسجلين والمتصفحين لنفس الموضوع في الوقت نفسه” مع ازدياد شعبية Discourse.
قد نحتاج إلى دعوة سلوك جديد عند حدوث ذلك، حيث يجب أن تبدأ لافتات “المسار السريع” بالظهور في واجهة الموضوع بشكل ما… 
أمر مهم يجب أخذه بعين الاعتبار هنا هو أن تطبيقات “الدردشة” عادةً ما تنشر المحتوى الفعلي للمشتركين.
في Discourse، لدينا خط أنابيب معقد إلى حد ما يجعل التنفيذ البسيط معقدًا، مما يؤدي إلى كميات كبيرة من حركة المرور.
(لدينا تحسينات مختلفة، وحدود للسرعة، وإعادة محاولات، وما إلى ذلك، لكن هذه هي الفكرة الأساسية)
يجب أن تعمل جميع هذه الطلبات عبر خط أماننا لضمان أن المستخدم لديه الصلاحية لرؤية المنشور وما إلى ذلك.
إذا كان المحتوى قصيرًا نسبيًا، وتمكنا من إيجاد طريقة لتنفيذ الأمان بطريقة أخف وزنًا لـ “المسار السريع”، فيمكننا حينها توزيع رسائل الدردشة عبر البث. وهذا سيؤدي إلى أداء أفضل بشكل ملحوظ، حيث يمكننا على الأرجح التعامل مع 10000 مستخدم على خادم رقمي صغير بسعة 2 جيجابايت من Digital Ocean بهذا التصميم.
الأمان معقد للغاية. كما أن التخزين المؤقت معقد أيضًا بسبب مشاكل إلغاء التخزين المؤقت.
لذلك، نعم، نحن نفكر بالتأكيد في هذه المشكلة. ولكن كما هو الحال حاليًا…
كثير من المشاهدين المسجلين في موضوع واحد + كثير من المحتوى الجديد في موضوع واحد = فواتير خادم باهظة.
هذا رائع!
بكل صراحة، أملك فقط ما يكفي من المعرفة لأكون خطرًا. أنا من النوع الذي يتعلم من خلال اللعب (والكسر). أقدر حقًا الجهد الرائع المبذول في إنشاء هذه المنصة. عندما أنشأت منتداي الأول قبل 12 شهرًا، أنشأت 12 نسخة مختلفة 
Vanilla و MyBB و SMF و Flarum وما إلى ذلك. كان Discourse هو الأفضل بلا منازع.
من أكبر المزايا هو التطوير النشط. إنه لأمر رائع أن نرى كيف تستمعون إلى المجتمع وتقومون باستمرار بالتحسينات.
هل لديك إعدادات موصى بها لهذا؟
مرحبًا يا رفاق، يبدو أن موقعي قد تراجع، مع نفس حزمة Digital Ocean (8 جيجابايت، 4 وحدات معالجة مركزية)، بدأ موقعي يعاني مع 60-70 مستخدمًا ينشرون 1000 مشاركة.
أتساءل عن شيئين فقط.
هل من الممكن إزالة رسالة الحمل الشديد؟ يبدو أنها تنبه المستخدمين أكثر من كونها مفيدة.
هل هناك أي تقدم في التعامل مع العدد الكبير من المستخدمين؟
في غضون ذلك، سأستكشف تعديل الـ unicorns، وتعطيل الإضافات وما إلى ذلك للمساعدة في تحرير الموارد.
إذا قمت بتغيير الحجم بعد التثبيت، هل قمت بتشغيل discourse-setup مرة أخرى أو قمت بتغيير الإعدادات يدويًا؟
لقد قمت بذلك يدويًا للتو، هل كان ينبغي علي تشغيل discourse setup؟
إذا قمت بإجراء التعديلات، فستحتاج إلى إعادة البناء (لست متأكدًا مما إذا كان الإيقاف/البدء سيفي بالغرض).
للتأكد فقط من أنني لا أساء الفهم، بعد تعديل ملف yml، قمت ببساطة بتشغيل ./launcher rebuild app
هل يستحق الأمر أن أجرب ./discourse-setup بدلاً من ذلك؟
(كما ذكرت من قبل، لدي معرفة كافية لأكون خطيرًا 
)
Should be fine. Discourse-setup will change the memory settings for you. If you did it then you should be fine.
فقط للتأكد وللاطلاع: هل لديك مبادلة مهيأة؟
لدي ملف مبادلة بحجم 2 جيجابايت، هل توصون بملف مبادلة بحجم 8 جيجابايت؟ (هل يتطابق مع حجم ذاكرة الوصول العشوائي؟)
إذا كانت لديك مساحة القرص، فإن المزيد من المبادلة لن يضر. سيخبرك free بكيفية استخدام الذاكرة ومقدار المبادلة المستخدمة.
