التنظيم في الطابور يعني أنه يمكنك استخدام عمال ويب (web workers) أكثر
بالإضافة إلى ذلك، تبدو أوقاتك المتوسطة مرتفعة إلى حد ما، هل يمكنك الحصول على معالج أسرع؟
للأسف، حتى لو كان سبب البطء هو هذه الإضافة، يجب أن أقول إنها واحدة من الإضافات الرئيسية لمجتمعنا ولا يمكن إزالتها بأي شكل من الأشكال، حيث أصبح المستخدمون معتمدين عليها بشكل كبير! 
نستخدم حاليًا 24 عامل ويب. تم تثبيت نظام Discourse الخاص بنا على آلة افتراضية تحتوي على 24 نواة معالج بسرعة معالجة 2 جيجاهرتز وذاكرة عشوائية (RAM) بسعة 24 جيجابايت. للأسف، لا يمكن تغيير الخادم الرئيسي الآن إلا إذا لم يكن هناك أي طريقة أخرى لتحسين الأداء.
هل تعتقد أن زيادة عدد عوامل الويب في الوضع الحالي يمكن أن تساعد في تحسين الأداء؟
قد يؤدي استخدام عمال ويب أكثر إلى تقليل وقت الانتظار
أنت تحاول إزالة الخطوط البرتقالية من مخطط طلبات الويب النشطة
ومع ذلك، لن تتحسن الأداء بشكل عام بالنسبة لمتوسط الطلبات النموذجية لديك
شكرًا لك، لقد فهمت الآن. إذن، من خلال النظر إلى الرسوم البيانية، يمكننا معرفة ما إذا كان عدد عمال الويب كافٍ أم لا لنظامنا.
لكن وفقًا لما تقوله، لتحسين السرعة والأداء، نحتاج الآن إلى قدرة معالجة أعلى، ولن يساعد تغيير المعاملات في ذلك بشكل أكبر.
تأكد من اختبار ذلك في أقرب فرصة ممكنة وأبلغنا بالنتيجة.
ما هو مصدر أخطاء 502؟ هل هو عدم وجود عدد كافٍ من عمال unicorn؟ لقد انتقلنا للتو إلى خوادم جديدة ويقوم المستخدمون بالإبلاغ عن أخطاء 502 بشكل متقطع بعد الانتقال. لدينا خادم 6C/16GB، وقد قمنا بتعيين unicorn_workers إلى 16 (قبل الانتقال إلى الخادم الجديد كان 12)، و db_shared_buffer إلى 4 جيجابايت، و db_work_mem إلى 60 ميجابايت.
هل يمكن أن يتسبب وجود عدد كبير جدًا من عمال unicorn في حدوث أخطاء 502؟ (تخمين نظرًا لأن لدينا 4 عمال أقل قبل ترحيل الخادم)
أحاول معرفة ما إذا كان التكوين هو ما نحتاج إلى تعديله أم شيء آخر نحتاج إلى معالجته.
شكرًا.
نعم، هذا يبدو مرتفعًا. اضبط عمال unicorn لديك بين 1 و 2 لكل نواة.
بالنسبة لـ 6 نوى، يجب ألا يزيد عن 12. نظرًا لمخزنك المؤقت المشترك الكبير نسبيًا وحدسي، سأضبطه على حوالي 10 بمواصفات الخادم هذه.