هناك أوامر مثل rake posts:rebake (أي بعد الترحيل).
هل توجد أوامر أخرى أو شيء آخر سيُسرع المنتدى؟ لدي انطباع بأن تغيير الاستضافة بذاكرة وصول عشوائي (RAM) أكبر جعلها ربما أبطأ حتى. زيادة الجيجابايت لم تساعد رغم أنني أتحقق دون أي حركة مرور. أتساءل عما إذا كانت هناك أوامر لتحسين قاعدة البيانات وما شابه، لأن هذا قد يكون السبب في أن التنقل عبر الروابط يستغرق وقتًا طويلاً وبطيئًا جدًا (1-2 ثانية). هذا الأمر مُحبط مقارنة بـ NodeBB، على سبيل المثال.
إذا قمت بتغيير ذاكرة الوصول العشوائي في خادمك، فيجب عليك تشغيل discourse-setup مرة أخرى لضبط إعدادات الذاكرة.
ما حجم قاعدة بياناتك؟ هل هذه استيراد أم مجتمع جديد؟ ما سرعة المعالج؟ تعتبر سرعة المعالج أحادي النواة حاسمة. هل تستخدم محركات أقراص صلبة SSD وليس أقراصًا دوارة، أليس كذلك؟
اختبار مثيلات Lightsail بسعة 2 جيجابايت من الذاكرة العشوائية، ووحدة معالجة مركزية واحدة، وقرص تخزين SSD بسعة 60 جيجابايت
أعتقد أن الإعدادات صحيحة:
UNICORN_WORKERS: 4
db_shared_buffers: "256MB"
هل يمكنك توضيح الأمر؟
تُوجَّه خدمة Lightsail فعليًا إلى تطبيقات الويب البسيطة والمواقع الإلكترونية.
لديك نواة معالج واحدة، مما يعني عمالي unicorn اثنين، ولكن يمكن زيادة قيمة shared_buffers إلى 512 ميجابايت. يجب أن يتضمن ملف app.yml هذا التعليق:
مع 2 جيجابايت نوصي بـ 3-4 عمال، ومع 1 جيجابايت عميلين فقط
إذن أنت تستخدم ضعف عدد العمال مع نصف حجم الذاكرة المؤقتة الموصى به.
الأقراص الميكانيكية هي ما سبق أقراص SSD، وقد تعرفها أيضًا باسم محركات الأقراص الصلبة أو HDD. وهي بطيئة جدًا لمنصة Discourse.
عادةً ما يتم ضبط هذه الإعدادات تلقائيًا بواسطة discourse-setup بناءً على مواصفات النظام (عدد أنوية المعالج، وكمية ذاكرة الوصول العشوائي) في وقت تشغيل السكربت. كما أنه من الآمن تشغيله مرة أخرى إذا تغيرت مواصفات الخادم.
هل تقصد أنه من الأفضل بكثير الاستثمار في أرخص خوادم EC2 ذات النواتين بدلاً من ذلك (وربما دمجها لاحقًا مع ELB)؟
هذا ما أستطيع رؤيته، فكل خادم على AWS لا يستخدم أقراص HDD.
هناك العديد من الاختلافات بين أنواع экземпляرات AWS. بعضها يستخدم أقراصًا مدعومة بـ EBS، مما يؤدي إلى الوصول إلى القرص عبر الشبكة وزيادة زمن الاستجابة. بينما يحتوي البعض الآخر على محركات NVMe محلية سريعة، لكنها لا تحفظ البيانات بشكل دائم. كما توجد عائلات экземпляرات Z و C التي توفر سرعة بيانات أعلى بكثير.
ومع ذلك، فإن كل هذا يصبح أكثر تعقيدًا وتكلفة مقارنة بـ Droplet من Digital Ocean، الذي يقدم أداءً مقبولاً للمجتمعات الصغيرة بسعر 5 دولارات، ويوفر معالجًا سريعًا جدًا في عرضهم المُحسّن للمعالج بسعر 40 دولارًا.
أي عرض بالضبط تقصده بـ “المُحسَّن”؟
بالمناسبة، ينطبق سؤالي أيضًا على الأوامر نفسها. أي أوامر (مثل “rake rebake posts”) يجب أن أشغّلها لتحسين أو إعادة بناء المنشورات أو حذف الملفات غير الضرورية، إلخ؟
لا يوجد شيء من هذا القبيل 
.
لماذا سيكون هناك أمر سري لجعل الأشياء سريعة؟ ولماذا على الإطلاق نبدأ بوضع بطيء؟
إذا كنت تواجه مشاكل في الأداء، فأنت بحاجة إلى تقديم بيانات ملموسة. ما هو المسار البطيء؟ ما هو حجم المجتمع؟ ما هو حجم قاعدة البيانات؟ هل جربت إزالة جميع الإضافات والقوالب؟ هل جربت التشغيل على قطرة DigitalOcean بسعر 5 دولارات، إلخ؟
هناك سابقة في هذا المجال 
لا توجد نية لإلقاء اللوم على أحد، خاصة أنني لم أفحص الأمر بنفسي، ولا سيما في ما يتعلق بمثيل PostgreSQL/إعداده… لكن Discourse بطيء للغاية. لست متأكدًا مما يتحمل المسؤولية عن ذلك، لكنني أظن أن ORM الخاص بـ Ruby يلعب دورًا في ذلك.
بالطبع، يمكنك دائمًا إضافة خادم أقوى، أو المزيد من وحدات التخزين SSD، أو المزيد من ذاكرة الوصول العشوائي (RAM)… إلى حد معين، لكن هذا لا يغير النقطة الرئيسية: Discourse يتطلب موارد كثيرة وهو بطيء نسبيًا، وحتى في التركيبات الصغيرة يتطلب استضافة جيدة.
حقًا؟ هل يمكنك دعم ذلك بأرقام من فضلك؟
بالمقارنة مع ماذا وفي أي ظروف؟
هل تعتبر ميتا بطيئة؟
أنا أختلف تمامًا مع هذه العبارة. فأنا أعرف عددًا من المجتمعات الصغيرة التي تعمل على خادم VPS بقيمة 5 دولارات. وعادةً ما يكون بطء تثبيت Discourse مؤشرًا على اختيار استضافة رديئة أو سوء التكوين.
تذكّر أن Discourse ليس موقعًا إلكترونيًا، بل هو تطبيق، وبمجرد تحميله في متصفحك، فإن البيانات المنقولة ذهابًا وإيابًا تكون ضئيلة.
إذا اتبعت دليل التثبيت القياسي، وهو دليل التثبيت الوحيد الذي ندعمه هنا، فإن جميع عمليات ضبط وحدة المعالجة المركزية/الذاكرة العشوائية تتم تلقائيًا. لم تقدم لنا أي أمثلة أو مقارنات هنا، وأحثك بشدة على تزويدنا ببعض التفاصيل المحددة.
بالتأكيد، يمكنني إجراء بعض المقارنات. أقوم بتشغيله على خادم افتراضي بقيمة 5 دولارات، بمعدات محدودة للغاية بمعايير اليوم، وأنا أدرك ذلك. لم أكن أقارنه بحلول منتديات أخرى، لكنني أعرف ما يمكن لـ PostgreSQL تقديمه حتى عند تشغيله في حاوية Docker ضمن بيئة افتراضية، حيث لدي خبرة تقارب 20 عامًا في تطوير قواعد البيانات.
حسناً، حسناً، وقد أثارتني قليلاً نبرة “هل تشغله على معدات من القرن الماضي، أي الأقراص الميكانيكية” 
سأعيد صياغتها إلى: “Discourse يتطلب موارد أكثر من الأنظمة الأبسط”.
كان التعليق قاسياً بعض الشيء، أوافق. انظر أعلاه
هل يمكنك شرح ما يعنيه مصطلح “سوء التكوين”؟ إنه يعني الأخطاء التي قد ترتكبها فعليًا عند تثبيت منتدى نظيف وإضافة ما يصل إلى 1-2 إضافة فقط. أي تكوين تقصده؟
@eextra تخطر ببالي عدة نقاط…
ما الذي تعتبره أداءً كافياً؟
صف السيناريوهات التي يحدث فيها تباطؤ في الأداء.
كيف حددت أن منصة Discourse (أو حتى استضافتك) هي مصدر هذا التباطؤ؟ وأن قاعدة البيانات عامل مقيد وما إلى ذلك.
ربما يمكنك مشاركة رابطين من webpagetest.org كنقطة انطلاق.
ورغم أن هذا صحيح تقنيًا، إلا أنني أعتقد أنه يغفل النقطة الجوهرية من منظور نمو المجتمع وتجربة المستخدم. هناك الكثير مما يُقال بشأن حجم الزيارات التي تجذبها مجتمعاتنا من محركات البحث.
في رأيي، من المهم أن يتم تحميل الرابط بسرعة عند الزيارة الأولى له.
وهو كذلك بالفعل - باستثناء المجتمعات كثيفة الأصول مثل NPN، لا أرى أي مجتمعات Discourse تتجاوز أوقات تحميلها النهائية ثانيتين، وعادةً ما يكون حدث DOMContentLoaded أقل بكثير من 1000 مللي ثانية.
تُعد أداة WebPageTest مقياسًا غير دقيق؛ افتح متصفحًا، افحص مصدر الصفحة، وانتقل إلى علامة التبويب “الشبكة”، ثم امسح ذاكرة التخزين المؤقت وأجبر على إعادة التحميل القوي. ستجد جميع الأرقام أمامك مباشرةً.
أنت تشير إلى وجود مشكلة، لكنك لم تقدم لنا أي أمثلة. سيكون من المفيد جدًا لو استطعت دعم هذه الادعاءات بأدلة.
إنها أداة صالحة تمامًا يمكن استخدامها كنقطة انطلاق، أو للتعمق في سيناريوهات محددة (نظام التشغيل، الموقع، عرض النطاق الترددي، زمن الوصول) إذا رغبت في ذلك. كما أنها طريقة مريحة لمشاركة نتيجة من سيناريو محدد للآخرين لمراجعتها.
إن تبويب الشبكة صالح تمامًا أيضًا، بشرط أن تدرك أنك ترى حرفيًا “تجربتك أنت” فقط، وغالبًا ما تكون من سطح المكتب عبر أي اتصال تتصل به. إنها اختبار حاسم جيد، يستغرق بضع ثوانٍ فقط، وقد يعطيك أو لا يعطيك ما تحتاجه لتحسين الأداء لزوارك.
كلا الطريقتين لهما مزايا. ولا يُعد أي منهما “مقياسًا سيئًا” على الإطلاق.
@eextra، يجدر بالذكر أيضًا أنه يجب أن يكون لديك عداد لوقت الاستجابة ظاهرًا عند تسجيل الدخول إلى discourse كمسؤول. كما تملك القدرة على تسجيل تقارير أداء NGINX عبر لوحة المسؤول.
ما المشكلة بالضبط في مواقع اختبار سرعة المواقع الإلكترونية؟
أود أن أضيف وجهة نظري لأني أستخدم هذه المواقع بكثرة وأجدها مفيدة. خاصة تلك التي تجري الاختبارات من مواقع متعددة وتكرر الاختبار عدة مرات في جلسة واحدة.
أجد الأمر مثيرًا للاهتمام أنني أحصل على نتائج مختلفة بين هذه المواقع ومتصفحِي عندما يتعلق الأمر بالتحسينات التي تؤثر على أوقات تتراوح بين 100 و200 مللي ثانية، رغم أنها تبدو دقيقة للوقت الأكبر من ذلك.
أحيانًا أختار تحسينات تجعل مواقع اختبار سرعة المواقع الإلكترونية سعيدة، لأنه إذا كانت جميعها تُظهر قياسات متشابهة، فأفترض أن جوجل تفعل ذلك أيضًا، رغم أنني قد أكون مخطئًا في ذلك لأن خوارزمتها مغلقة.
لغة روبي معروفة بأنها بطيئة، وDiscourse يستخدم كمية هائلة من جافا سكريبت، ولا يُنكر أن وقت التحميل الأولي لمنصة نقاش Discourse طويل، وأن سرعتها على الأجهزة المحمولة ضعيفة. أعتقد أن إخبار الناس بأنهم سيحصلون على نتائج سرعة ممتازة مع الأجهزة المناسبة ليس دقيقًا تمامًا، فأتصفح ميتا الآن وهي بطيئة فعليًا مقارنةً… بمنصة نقاش مبرمجة بلغة Go على سبيل المثال، ضحكة. أنا أستخدم Discourse لأنه يعمل بشكل جيد، ويتميز بمكافحة قوية للرسائل المزعجة، وميزات رائعة، وصيانة منخفضة. لكنني لم أفكر أبدًا أنه سريع، ولا يعتبر معظم زوار المنتدى أنه “تطبيق” عندما ينقرون على أول رابط من جوجل لزيارة الموقع.