it-swarm.asia

ما الذي يساهم في drupal وقت تنفيذ الصفحة؟

لدي موقع أقوم بالتحقيق فيه ولديه مشاكل كبيرة في الأداء ، باستخدام memcache ، تمكنت من تقليل عدد الاستعلامات من حيث العدد والوقت الكلي للتنقيب (من 3 ثوانٍ إلى 230 مللي ثانية) ولكن وقت تنفيذ الصفحة يراوغني (أنا بالنظر إلى القيم الناتجة عن devel) ما أفهمه هو أن وقت تنفيذ الصفحة = الوقت الذي يستغرقه تنفيذ php ، لذلك قمت بتثبيت APC ويمكنني رؤية كود php المخبأ وإحصائيات تعرض النتائج في لوحة تحكم APC (apc.php يتم شحنها مع APC) ولكن لا ينخفض ​​وقت تنفيذ صفحتي. لذلك أعتقد أن سؤالي ذو شقين:

  • ما الذي يساهم في تنفيذ الصفحة (يبطئ بشكل أفضل)؟ هل حان الوقت لتنفيذ php؟
  • ما هي الأساليب التي يجب علي اتباعها لتقليل وقت تنفيذ الصفحة. حاولت APC ولكن ليس الكثير من المساعدة

ملاحظة: عدد الوحدات المستخدمة في هذا الموقع ضخم للغاية (168) ولكن الآن لست في وضع يسمح لي بتقديم هذه التوصية ، فهي أشبه بالحريق في حالة الثقب.

تحرير: ناتج تشغيل xhprof على سبيل المثال المحلي (موصى به من قبل mikeytown) ، يبدو هذا مجنونًا أعتقد أن النتائج الأخيرة ناتجة عن التحطم؟ يعمل الاختلاف عن نفس عنوان URL على اختلاف كبير واستخدامه الكثير من الموارد. لست متأكدًا أيضًا من سبب إظهار القيم التي ليست من اليوم: | (لقد قمت للتو بتثبيت xhprof على هذا الكمبيوتر المحمول)

Output of running xhprof on local instance

16
Dipen

احصل على نسخة مخبأة من موقعك. xdebug أو xhprof يمكنه إنشاء واحد. سيخبرك هذا بالوظائف التي تستغرق وقتًا أطول في التشغيل. حتى تفعل ذلك ، إنها لعبة تخمين سيئة.

4
mikeytown2

تحرير: لقد أسأت قراءة المنشور الأصلي. 168 وحدة هو الكثير ، و 300 إلى 700 مللي ثانية من استعلامات SQL ضخمة. كلما زاد عدد الوحدات التي ستستخدمها ، كلما زاد عدد الاستفسارات التي سيتم إجراؤها بمجرد أن تقوم الوحدات ببعضها.

استخدم التخزين المؤقت العدواني بينما يمكنك تخزين كل شيء مؤقتًا ، إذا لم يكن كافيًا ، فجرّب ذاكرة تخزين مؤقت عكسية للخادم الوكيل. يمكن أن يؤدي استخدام CDN للملفات إلى تحسين كل شيء بشكل كبير. يمكن أن تساعدك ذاكرة التخزين المؤقت للخادم الوكيل العكسي أيضًا عن طريق إزالة بعض ملفات تعريف ارتباط المصادقة عند النقر على الصفحات التي لا تحتاج إليها (عندها سيعتقد Core أن المستخدم مجهول لهذه الملفات ويزيد التخزين المؤقت إلى أقصى حد).


ديناميكية Drupal الأساسية تجعل الفجر كله بطيئًا بمجرد أن يكون لديك عدد كبير جدًا من الوحدات التي تتفاعل في نفس الوقت.

أود أن أقول ، على سبيل المثال ، إذا كنت تستخدم الكثير من الوحدات النمطية التي تقوم بتحميل البيانات في وقت hook_node_load () بدلاً من استخدام الحقول ، فستقوم بإجراء الكثير من الاستعلامات بينما سيضمن استخدام الحقل كفاءة التخزين المؤقت.

يمكن أن يستغرق التقديم وقتًا طويلاً أيضًا ، drupal_render () (واجهة برمجة تطبيقات العرض التي يتم استدعاؤها أحيانًا) هي جزء من واجهة برمجة التطبيقات (مفيد حقًا) ولكنها بطيئة بعض الشيء أيضًا. التبديل إلى PDO (D7) و DBTNG الكامل (وهو أمر رائع بالمناسبة) يضيفان أيضًا كمونًا غير قابل للتجاهل.

ومع ذلك ، فإن Core في حد ذاته سريع جدًا (ولكنه يفعل الكثير من استعلامات SQL ، حتى مع عدم تثبيت أي شيء تقريبًا) ، غالبًا ما تكون الوحدات ذات الترميز السيء هي عنق الزجاجة.

يمكن لـ APC تقسيم وقت التنفيذ لكل 2 أو 3 ، اعتمادًا على الرمز الذي يتم تشغيله. إذا قمت بتكوينه بشكل جيد (تمكين جميع تحسينات APC ، فإن دليل APC الرسمي مكتوب بشكل جيد وسيوجهك).

إذا كنت في صندوق به نظام ملفات بطيء (نظام ملفات شبكة أو محرك أقراص ثابت بطيء) فقد يعني ذلك تأثيرًا واضحًا على وقت التنفيذ. Drupal مصنوع من الكثير من الملفات الصغيرة ، مما يجبر PHP على إجراء الإدخال/الإخراج على FS في كل مرة يقوم بتحميل أحدها (APC أيضًا يساعد كثيرا على ذلك).

يمكن أن يكون نظام إدارة قواعد البيانات (DBMS) الذي تم تكوينه بشكل خاطئ أيضًا اختناقًا قبيحًا تمامًا ، إذا كنت تستخدم MySQL فكر في إجراء الضبط الدقيق. إذا كنت تستخدم استضافة مشتركة ، إذا لم يكن Drupal DBMS و PHP محددًا (أو جاهزًا) من المحتمل أن يكون مكوّنًا بشكل غير صحيح أو غير مضبوط ، مما قد يؤدي إلى مواقع بطيئة حقًا.

لا تنسى تفعيل جميع المخابئ. إذا كان موقعك غير مصادق عليه من قبل المستخدم ، فعندئذ قم بتفعيل التخزين المؤقت للصفحة (إنه أمر رائع حقًا).

كلما كان لديك المزيد من الكتل ، كلما كانت الصفحات الكاملة أكثر بطيئة ، وستكون كتل وحدة Views هي عنق الزجاجة (اعتمادًا على المكونات الإضافية Views التي تستخدمها ، يمكن أن يكون حظر OG مؤلمًا حقيقيًا) إذا لم تقم بتقييد رؤيتها على أساس كل صفحة ، أو باستخدام رمز PHP مخصص (أي كتلة أخرى أيضًا ، قم دائمًا بتعيين رؤية الكتلة يدويًا ، ويساعد الإطار بشكل كبير عن طريق تجنبه لمحاولة تقديم كتل فارغة).

تجنب الوحدات التي تستخدم hook_init () و hook_init () التي يتم تشغيلها في كل صفحة ، حتى إذا حصلت على 403 أو 404 ، مما يؤدي إلى إبطاء كل شيء (حتى أنه يبطئ ذاكرة التخزين المؤقت | نمط جيل النمط ، وأخطاء 404 على الملفات ستكون فجر بطيء فقط لأخبرك أن الملف غير موجود).

1
Pierre