لقد قمت للتو بتثبيت Discourse، ولكن الصفحات تتطلب وقتًا طويلًا للتحميل بسبب قاعدة بيانات خارجية بطيئة

الصفحة الرئيسية تستغرق 2-4 ثوانٍ للاستجابة

بدأ GET "/" لـ 219.144.218.209 في 2025-03-17 18:22:55 +0000

معالجة بواسطة ListController#latest كـ HTML

تم عرض التخطيط layouts/application.html.erb (المدة: 1932.6 مللي ثانية | GC: 10.6 مللي ثانية)

اكتمل 200 OK في 2521 مللي ثانية (طرق العرض: 1933.4 مللي ثانية | ActiveRecord: 0.0 مللي ثانية (0 استعلام، 0 مخزن مؤقت) | GC: 14.9 مللي ثانية)

يحتوي خادمي على نواتي معالج و 8 جيجابايت من ذاكرة الوصول العشوائي.

يُظهر السجل أن layouts/application.html.erb تم عرضه ببطء شديد.

لقد قمت بإزالة بعض المحتوى في layouts/application.html.erb واستغرق الأمر ما يصل إلى 300-500 مللي ثانية للاستجابة.


<discourse-assets>
    <discourse-assets-stylesheets>
      <%= render partial: "common/discourse_stylesheet" %>
    </discourse-assets-stylesheets>
    <discourse-assets-json>
      <div class="hidden" id="data-preloaded" data-preloaded="<%= preloaded_json %>"></div>
    </discourse-assets-json>
    <discourse-assets-icons></discourse-assets-icons>
  </discourse-assets>

يستهلك كل طلب مستخدم كمية كبيرة من وحدة المعالجة المركزية.
من فضلك ساعدني.

هل قمت بالتثبيت القياسي؟

إعجابَين (2)

نعم، لقد فعلت.
ووجدت مشكلة بالأمس.
لقد استخدمت قاعدة بيانات بعيدة، ومكون التخطيط الخاص بـ discourse يجلب أكثر من 60 استعلام SQL، وكل استعلام SQL يحتاج إلى ±30 مللي ثانية للنقل، لذا فإن أول عرض يستغرق 2-4 ثوانٍ.
تختفي المشكلة عندما قمت بالتغيير إلى قاعدة بيانات محلية.

إعجاب واحد (1)

نعم، إنه كذلك:

أواجه مشكلة مماثلة.
أعتقد أن الدوكر يقوم بنوع من الفهرسة السحرية على قواعد البيانات الداخلية فقط، وهذا ليس جيدًا لأنه يحد بشكل كبير من كيفية التوسع.

هممم … هذا لا يبدو صحيحًا بالنسبة لي. يجب تطبيق نفس عمليات الترحيل بغض النظر عن مكان وجود قاعدة البيانات … وهذا يشمل إضافة الفهارس.

سيكون من الجيد توضيح الفرق إذا كان بإمكانك الحصول على خطة استعلام على كلا المثيلين لنفس الاستعلام الذي يستغرق وقتًا أطول بكثير على المثيل الخارجي.

(نقدر أن هذا قد يكون مؤلمًا لك لجمعه)

إذا كانت خطة الاستعلام متطابقة، فمن المؤكد أن يكون الخطأ في زمن الاستجابة أو أداء قاعدة البيانات الخارجية؟

لدي هذه الخطة التي قمت بها منذ فترة استعلام طويل الأمد:

كانت هذه الخطة قاعدة بيانات مستضافة محليًا، وكانت عمليات الإدخال/الإخراج على القرص هي المشكلة هناك، ولهذا السبب انتقلت إلى قاعدة بيانات خارجية.

أنا أحاول إعادة البناء باستخدام قاعدة بيانات داخلية.

إعجاب واحد (1)

هذا مقدار كبير جدًا من الوقت نسبيًا. هناك خطأ ما في إعدادات SQL الخاصة بك.

ما مدى بعد قاعدة البيانات؟

النسبة المئوية 99% من إجمالي وقت SQL للطلبات المسجلة الدخول على meta (المستضافة في AWS) هي ~54 مللي ثانية، وعلى الاستضافة الخاصة بنا لموقع مشابه هي ~25 مللي ثانية.

المستخدم المجهول حوالي 40 مللي ثانية و 10 مللي ثانية.

يبدو أنك تعمل في وضع التطوير، وليس تثبيتًا قياسيًا.

إعجاب واحد (1)