يبلغ عدد مستخدمي موقع Discourse لدينا أكثر من 10 آلاف مستخدم، مع حوالي 700 مستخدم نشط يوميًا، حيث يُرسل المستخدمون في المتوسط 10 آلاف منشور يوميًا. كما يتجاوز عدد مشاهدات الصفحات في مجتمعنا 160 ألف مشاهدة يوميًا، بما في ذلك الزوار الآليون والمستخدمون المجهولون. ومعظم مستخدمينا يتصلون بنا عبر الأجهزة المحمولة.
قمنا بتشغيل المجتمع في وضع الإعداد المستقل على خادم افتراضي خاص (VPS) واحد يحتوي على 16 نواة معالجة وذاكرة عشوائية (RAM) سعتها 24 جيجابايت، وقمنا بتكوين ملف app.yml بالقيم التالية:
مع الإعدادات المذكورة أعلاه، أفاد بعض المستخدمين بأن الموقع يُحمّل ببطء بالنسبة لهم، وفي بعض الأحيان عند إرسال منشور، تظهر الشاشة فارغة (مع بقاء الرأس الظاهر). كما أن أداء الموقع يتباطأ أحيانًا خلال ساعات الذروة.
يرجى توضيح ما إذا كان هناك خطأ في الإعدادات أم أننا نحتاج إلى موارد إضافية.
شكرًا جزيلاً
10,000 منشورًا يوميًا يعتبر عددًا مرتفعًا نسبيًا مقارنة بعدد مشاهدات الصفحة. أتخيل أنك قد تصل إلى بعض حدود الموارد هنا نظرًا لإعداداتك، وأظن أن المشكلة تكمن في قاعدة البيانات. يمكنك محاولة الانتقال إلى إعداد متعدد الحاويات، مما يؤدي فعليًا إلى تفريغ عمال يونيكورن من الخادم الرئيسي.
بناءً على إجابتك، هل يعني ذلك أن زيادة الموارد في هذا الإعداد لا تساعد في حل مشكلتنا؟ على سبيل المثال، 24 نواة مع 32 جيجابايت من ذاكرة الوصول العشوائي.
قد يكون ذلك صحيحًا، لكنني سأحاول أولاً توسيع أي شيء يمكن توسيعه أفقيًا، بشكل أفقي. كما سيساعدك ذلك في تحديد مكان الاختناق بدقة أكبر.
يمكن حل معظم مشكلات الأداء ببساطة عن طريق تخصيص المزيد من الموارد للمشكلة. الجزء الصعب هو القيام بذلك بطريقة ذكية لتتمكن من توفير بعض المال (أو ربما مبلغ كبير من المال).
شكرًا لخبرتك ونصائحك الودية، سأقرأ بالتأكيد حول كيفية تنفيذ ذلك. لدي سؤال آخر: ما هي الإعدادات التي يجب تطبيقها في التطبيق للمواصفات التي ذكرتها أعلاه (24 نواة معالج و32 جيجابايت من الذاكرة العشوائية)؟
هل الإعدادات الحالية مناسبة أم من الأفضل زيادة القيم؟
بما أنك ذكرت أن معظم المشاكل تحدث عند نشر منشور، فالأرجح أن المشكلة تتعلق بعمليات الكتابة إلى قاعدة البيانات، ولا أعتقد أن زيادة shared buffers أكثر من ذلك ستفيد كثيرًا، لكن يمكنك المحاولة. لقد رأيتُها مُرفعة لأكثر من 50% من الذاكرة (مخالفًا لكل النصائح)، لذا يمكنك محاولة رفعها تدريجيًا حتى 12 جيجابايت.
إذا لم تكن ترى أخطاء 502، فلا فائدة من زيادة UNICORN_WORKERS أيضًا.
لم تذكر استخدام ذلك، لذا أعتقد أن أول ما سأقوم به هو إضافة شبكة توصيل محتوى (CDN)، وهذا سيقلل بشكل كبير من العبء على الخادم الافتراضي الخاص بك (VPS) حيث لن تصل الطلبات الكبيرة إلى الخادم.
بالإضافة إلى شبكة توصيل المحتوى، أنصحك أيضًا بالذهاب مع تخزين مشابه لـ S3، مما يسمح لك بتوسيع نطاق التخزين وموارد الخادم الافتراضي (VPS) بشكل منفصل (إذا كانت مجتمعتك تعتمد بشكل كبير على التحميلات).
هذه التوصيات تساعد بشكل كبير في تقليل الحمل، كما أن زيادة السعر أقل بكثير مقارنة بترقية إلى خادم افتراضي (VPS) أكبر.
شكرًا لك @marianord، للأسف لا نستخدم CDN. معدل الرفع في منتدانا ليس مرتفعًا جدًا. في معظم الأوقات، يتحدث المستخدمون حول مواضيع مختلفة. على سبيل المثال، في العام الماضي، كان لدينا حوالي 2.8 مليون منشور و2.7 مليون إعجاب، ولكن تم رفع ملفات بحجم 25 جيجابايت فقط.
هل تعتقد أنه بناءً على المعلومات التي كتبتها، سيؤدي استخدام CDN مثل S3 إلى تقليل الحمل على خادمنا؟
أنا لا أوافق على @marianord. لا أعتقد أن شبكة توصيل المحتوى (CDN) ستحدث فرقًا ملحوظًا فيما يتعلق بالعبء على خادمك. هذه مجرد ملفات ثابتة وليست ثقيلة الخدمة على الإطلاق.
يقوم S3 بنقل الملفات والنسخ الاحتياطية إلى خادم آخر يديره مزود سحابي (ملخص عالي المستوى جدًا)
تقوم CDN بتخزين الملفات الثابتة لخادمك (الصور، ملفات JS، ملفات CSS) مؤقتًا لتخدمها من خوادم متعددة (نقاط الوجود) حول العالم لتسريع تحميل هذه الأصول.
على الأقل هذا هو تجربتي؛ فأنت تقلل عدد الطلبات التي تصل إلى خادمك، مما يقلل العبء. من الأسهل بكثير خدمة 10 طلبات JSON لكل مستخدم بدلاً من خدمة 100 طلب لكل مستخدم.
ربما لن يحل هذا جميع المشكلات التي يواجهها @nildarar، لكنه سيخفف العبء الثقيل على الخادم من خلال إزالة جميع الطلبات الثابتة (المخزنة مؤقتًا) من خادم Discourse.
صحيح، لكن Discourse يحتوي على بعض الاستثناءات، مثل أوراق الأنماط التي يتم تقديمها بواسطة Ruby، لذا فإن وجود CDN ذا ذاكرة تخزين مؤقت يعني أن هذه الطلبات لا تستهلك عمليات Unicorn.
بشأن مشكلة المنشور الأصلي، فإن أول ما يحتاج إليه هو وجود شخص خبير يقوم بإجراء تحليل للأداء خلال ساعات الذروة وتحديد الاختناق الحالي.
شكرًا على إرشاداتك. حتى قبل بضعة أشهر، كنا نستخدم خدمة Cloudflare CDN وقمنا بإجراء تحسينات جيدة للمحتوى الثابت من خلال قواعد الصفحات. بعد ذلك، قرأت في مكان ما أن استخدام وكلاء مثل Cloudflare يقلل بشكل كبير من أداء Discourse، لذا قمنا بإيقافه.
أمس، قمنا بزيادة عدد أنوية المعالج من 16 إلى 24 وقمنا بإجراء التغييرات التالية في ملف app.yml:
قد تكون هذه المعلومات قديمة، لكنني أتذكر أنني قرأت أن discourse تفضل عددًا أقل من وحدات المعالجة المركزية (CPU) الأقوى مقارنة بعدد أكبر من الوحدات الأضعف، حتى لو قمت بتحديث عدد عمال يونيكورن.
@codinghorror، هل يمكنك تأكيد ما إذا كانت هذه المعلومات لا تزال دقيقة؟
مرحبًا مجددًا
بناءً على نصائحكم، قمنا بتثبيت Prometheus ومراقبة أداء المجتمع لفترة من الوقت. يرجى الاطلاع على التقارير أدناه ومقارنتها بالقيم التي تظهر في التثبيتات المختلفة.
