تحسين مواقع الويب المستندة إلى Kohana للسرعة والتوسع

Question

انتقد موقع بنيت مع كوهانا بمقدار هائل من حركة المرور أمس، مما تسبب في اتخاذ خطوة إلى الوراء وتقييم بعض التصميم. أنا فضولي ما هي بعض التقنيات القياسية لتحسين التطبيقات القائمة على kohana؟

أنا مهتم بمعايير كذلك. هل أحتاج إلى الإعداد Benchmark::start() و Benchmark::stop() لكل طريقة تحكم من أجل رؤية أوقات التنفيذ لجميع الصفحات، أو أنا قادر على تطبيق المعايير على مستوى العالم وبسرعة؟

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

Answer 1

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

فيما يلي بعض النقاط التي تأتي إلى ذهني عند الحديث عن الأداء، قابلية التوسع، PHP، ...
لقد استخدمت العديد من هذه الأفكار أثناء العمل في العديد من المشاريع - وساعدت؛ لذلك ربما يمكن أن تساعد هنا أيضا.

بادئ ذي بدء، عندما يتعلق الأمر بالعروض، هناك العديد من الجوانب / الأسئلة التي يجب مراعاتها:

• تكوين الخادم (كلا Apache، PHP، MySQL، Daemons المحتمل الأخرى، والنظام); ؛ قد تحصل على المزيد من المساعدة حول ذلك ServerFault., ، أقترح - أرى - أحبذ،
• رمز PHP،
• استعلامات قاعدة البيانات،
• باستخدام أم لا خادم الويب الخاص بك؟
• هل يمكنك استخدام أي نوع من آلية التخزين المؤقت؟ أو هل تحتاج دائما إلى أحدث البيانات على موقع الويب؟

باستخدام وكيل عكسي

أول شيء يمكن أن يكون مفيدا حقا هو استخدام عكس الوكيل, ، مثل ورنيش, ، أمام خادم الويب الخاص بك: اتركه ذاكرة التخزين المؤقت أكبر عدد ممكن من الأشياء, ، لذلك فقط يطلب فقط أن تحتاج إلى حسابات php / mysql (وبالطبع، بعض الطلبات الأخرى، عندما لا تكون في ذاكرة التخزين المؤقت للوكيل) اجعلها Apache / PHP / MySQL.

• بادئ ذي بدء، CSS / جافا سكريبت / صور - حسنا، كل ما هو ثابت - ربما لا تحتاج إلى أن تكون دائما يخدمها أباتشي
  • لذلك، يمكنك الحصول على ذاكرة التخزين المؤقت العكسي الوكيل كل تلك.
  • خدمة تلك الملفات الثابتة ليست مشكلة كبيرة لأباش، ولكن الأقل يجب أن تعمل من أجل هؤلاء، كلما زاد من القيام به مع PHP.
  • تذكر: يمكن ل Apache فقط أن خادم محدود ومحدود عدد الطلبات في وقت واحد.
• ثم، يكون الوكيل العكسي بمثابة العديد من صفحات PHP قدر الإمكان من ذاكرة التخزين المؤقت: ربما يكون هناك بعض الصفحات التي لا تتغير في كثير من الأحيان, ، ويمكن تقديمها من ذاكرة التخزين المؤقت. بدلا من استخدام بعض ذاكرة التخزين المؤقت المستندة إلى PHP، لماذا لا تدع آخر، أخف، يخدم الخادم (وجلبها من خادم PHP من وقت لآخر، لذلك دائما ما يقرب من تاريخ)?
  • على سبيل المثال، إذا كان لديك بعض الأعلاف RSS (نميل عموما إلى أن ننسى تلك الموجودة، عند محاولة تحسين الأداء) التي طلبت غالبا, ، يمكن أن يوفرها في ذاكرة التخزين المؤقت لبضع دقائق من توفير مئات / آلاف الطلب إلى Apache + PHP + MySQL!
  • نفسه بالنسبة للصفحات الأكثر زيارة من موقعك، إذا لم تتغير لمدة بضع دقائق على الأقل (مثال: الصفحة الرئيسية؟), ، إذن، لا حاجة إلى إضاعة وحدة المعالجة المركزية إعادة إنشاءها في كل مرة يطلب فيها المستخدم.
• ربما هناك فرق بين الصفحات المقدمة للمستخدمين المجهولين (نفس الصفحة لجميع المستخدمين المجهولين) والصفحات التي تخدم للمستخدمين المحددين ("مرحبا MR X، لديك رسائل جديدة"، على سبيل المثال)?
  • إذا كان الأمر كذلك، فربما يمكنك تكوين الوكيل العكسي الخاص بتخزين الصفحة التي يتم تقديمها للمستخدمين المجهولين (بناء على ملف تعريف ارتباط، مثل ملف تعريف ارتباط الجلسة، عادة)
  • سيعني أن Apache + PHP لديه أقل للتعامل مع: المستخدمين المحددين فقط - والتي قد تكون جزءا صغيرا فقط من المستخدمين.

حول باستخدام وكيل عكسي كذاكرة التخزين المؤقت, بالنسبة لتطبيق PHP، يمكنك، على سبيل المثال، إلقاء نظرة على تظهر النتائج القياسية زيادة 400٪ -700٪ في إمكانيات الخادم مع APC وذاكرة التخزين المؤقت الحبار.
(نعم، إنهم يستخدمون الحبار، وكنت أتحدث عن الورنيش - هذا مجرد احتمال آخر ^ ^ ورنيش كونه أحدث، ولكن أكثر مخصصة للتخزين المؤقت)

إذا قمت بذلك جيدا بما فيه الكفاية، وتمكن من إيقاف إعادة إنشاء الكثير من الصفحات مرارا وتكرارا، فربما لن تضطر إلى تحسين أي من التعليمات البرمجية الخاصة بك ؛-)
على الأقل، ربما ليس في أي نوع من الرش ... من الأفضل دائما إجراء التحسينات عندما لا تكون تحت الكثير من الحضور ...

كما Sidenote: أنت تقول في المرجع:

تم انشهار موقع بنيت مع كوهانا بمقدار هائل من حركة المرور أمس،

هذا هو هذا النوع من موقف مفاجئ حيث يمكن للوكالة العكسي أن ينقذ اليوم, ، إذا كان بإمكان موقع الويب الخاص بك التعامل مع عدم وجود محدث بالثاني:

• تثبيته، تكوينه، واتركها دائما - كل يوم طبيعي - يركض:
  • تكوينه لعدم الحفاظ على صفحات PHP في ذاكرة التخزين المؤقت؛ أو فقط لمدة قصيرة؛ بهذه الطريقة، لديك دائما ما يصل إلى تاريخ البيانات المعروضة
• وفي اليوم الذي تأخذ فيه تأثير Slashdot أو Digg:
  • تكوين الوكيل العكسي للحفاظ على صفحات PHP في ذاكرة التخزين المؤقت؛ أو لفترة أطول من الوقت؛ ربما لن تكون صفحاتك محدثة من قبل الثانية، لكنها ستسمح بموقع الويب الخاص بك للبقاء على قيد الحياة من تأثير Digg!

عن ذلك، كيف يمكنني الكشف عن كونك "سلاسة"؟ قد يكون قراءة مثيرة للاهتمام.

على جانب PHP من الأشياء:

بادئ ذي بدء: هل تستخدم النسخة الأخيرة من PHPب هناك تحسينات بانتظام في السرعة، مع إصدارات جديدة ؛-)
على سبيل المثال، نلقي نظرة على معيار PHP Branches 3.0 من خلال 5.3 CVS.

لاحظ أن العروض هي سبب وجيه لاستخدام PHP 5.3 (لقد قدمت بعض المعايير (باللغة الفرنسية), ، والنتائج رائعة)...
سبب وجودي آخر يجري، بالطبع، أن PHP 5.2 قد وصلت إلى نهاية حياته، ولا يتم الحفاظ عليه بعد الآن!

هل تستخدم أي ذاكرة التخزين المؤقت Opcode؟

• أنا أفكر ب APC - ذاكرة التخزين المؤقت البديل PHP, ، على سبيل المثال (خفي, كتيب), ، وهذا هو الحل الذي رأيته يستخدم أكثر - وهذا يستخدم على جميع الخوادم التي عملت عليها.
  • أنظر أيضا: الشرائح APC Facebook.,
  • أو تظهر النتائج القياسية زيادة 400٪ -700٪ في إمكانيات الخادم مع APC وذاكرة التخزين المؤقت الحبار.
• يمكن أن تقلل حقا تحميل وحدة المعالجة المركزية للخادم كثيرا، في بعض الحالات (لقد رأيت تحميل وحدة المعالجة المركزية على بعض الخوادم تذهب من 80٪ إلى 40٪، فقط عن طريق تثبيت APC وتفعيل وظيفة ذاكرة التخزين المؤقت في OPCODE!)
• أساسا، ينطبق تنفيذ البرنامج النصي PHP على خطوتين:
  • تجميع رمز مصدر PHP إلى Opcodes (نوع ما يعادل جافا bytecode)
  • تنفيذ تلك opcodes
  • يحتفظ APC في الذاكرة، لذلك هناك عمل أقل يجب القيام به في كل مرة يتم تنفيذ البرنامج النصي / الملف PHP: فقط جلب The Opcodes من ذاكرة الوصول العشوائي، وتنفيذها.
• قد تحتاج إلى إلقاء نظرة على APC خيارات الإعداد, ، على فكرة
  • هناك عدد كبير من هؤلاء، ويمكن أن يكون لدى البعض تأثير كبير على كل من السرعة / وحدة المعالجة المركزية - سهولة الاستخدام لك
  • على سبيل المثال، تعطيل [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat) يمكن أن تكون جيدة لتحميل النظام؛ ولكن هذا يعني التعديلات التي تم إجراؤها على ملفات PHP لن تأخذ في الاعتبار إلا إذا قمت باستدلال ذاكرة التخزين المؤقت Opcode بالكامل؛ حول ذلك، لمزيد من التفاصيل، انظر على سبيل المثال إلى القانون () أو عدم القانون ()؟

باستخدام ذاكرة التخزين المؤقت للبيانات

قدر الإمكان، من الأفضل تجنب القيام بنفس الشيء مرارا وتكرارا.

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

قد يكون مثيرا للاهتمام للغاية بالنسبة لك لتحديد:

• التي تستفسر تشغيل الكثير من المرات، دائما إعادة نفس البيانات
• أيها أخرى (ثقيل) يتم إجراء الحسابات الكثير من الوقت، دائما إعادة نفس النتيجة

وتخزين هذه البيانات / النتائج في نوع من ذاكرة التخزين المؤقت، لذلك فهي أسهل للحصول على أسرع - وليس لديك للذهاب إلى خادم SQL الخاص بك ل "لا شيء".

آليات التخزين المؤقت كبيرة هي، على سبيل المثال:

• APC.: بالإضافة إلى ذاكرة التخزين المؤقت Opcode تحدثت في وقت سابق، فإنه يسمح لك بتخزين البيانات في الذاكرة،
• و / أو memcached. (أنظر أيضا), ، وهذا مفيد جدا إذا كان لديك حرفيا الكثير البيانات و / أو هي باستخدام خوادم متعددة, ، كما يتم توزيعها.
• بالطبع، يمكنك التفكير في الملفات؛ وربما العديد من الأفكار الأخرى.

أنا متأكد من أن إطار عملك يأتي مع بعض الأشياء المتعلقة بالذاكرة التخزين المؤقت؛ ربما تعرف ذلك بالفعل، كما قلت "سأكون استخدام مكتبة التخزين المؤقت أكثر في الوقت المناسب ليأتي" في المرجع ؛-)

التنميط

الآن، شيء لطيف يجب القيام به سيكون استخدام Xdebug. التمديد إلى الملف الشخصي طلبك: غالبا ما يسمح للعثور على بضع نقاط ضعيفة بسهولة - على الأقل، إذا كان هناك أي وظيفة تأخذ الكثير من الوقت.

تكوينها بشكل صحيح, ، سيولد ملفات التنميط التي يمكن تحليلها مع بعض أدوات الرسومات، مثل:

• kcachegrind.: المفضلة، ولكنها تعمل فقط على Linux / KDE
• Wincachegrind. للنوافذ؛ الأمر أقل الأشياء قليلا من kcachegrind، لسوء الحظ - لا يعرض callgraphs، عادة.
• WebGrind. الذي يعمل على خادم الويب PHP، لذلك يعمل في أي مكان - ولكن ربما يكون لديه ميزات أقل.

على سبيل المثال، فيما يلي Screenshots زوجين من KCachegrind:

<sub>(مصدر: pascal-martin.fr.)

(مصدر: pascal-martin.fr.)</sub>

(راجع للشغل، فإن Callgraph المقدم في لقطة الشاشة الثانية هو عادة شيء لا يمكن أن يفعله Wincachegrind أو WebGrind، إذا كنت أتذكر بشكل صحيح ^^)

(شكرا @ mikushi للتعليق) احتمال آخر لم أستخدمه كثيرا xhprof. التمديد: كما أنه يساعد أيضا في التنميط، يمكن أن تولد Callgraphs - ولكن أخف وزنا من XDebug، مما يعني أنه يجب أن تكون قادرا على تثبيته على خادم الإنتاج.

يجب أن تكون قادرا على استخدامها على Alonside Xhgui., ، والتي ستساعد على تصور البيانات.

على جانب SQL من الأشياء:

الآن بعد أن تحدثنا قليلا عن PHP، لاحظ أنه أكثر من ممكن أن الاختناق الخاص بك ليس الجانب php من الأشياء, ، ولكن قاعدة البيانات واحدة ...

ما لا يقل عن شيئين أو ثلاثة أشياء، هنا:

• يجب عليك تحديد:
  • ما هي الاستعلامات الأكثر شيوعا التطبيق الخاص بك يفعل
  • ما إذا كانت تلك الأمثل (باستخدام الفهارس اليمنى, ، في الأساس؟), ، باستخدام EXPLAIN تعليمات، إذا كنت تستخدم MySQL
    • أنظر أيضا: تحسين الاختيار والبيانات الأخرى
    • يمكنك، على سبيل المثال، تنشيط log_slow_queries للحصول على قائمة بالطلبات التي تأخذ "كثير جدا" الوقت، وبدء التحسين الخاص بك من قبل هؤلاء.
  • ما إذا كان يمكنك التخزين المؤقت بعض هذه الاستفسارات (انظر ما قلته سابقا)
• هل تكوين MySQL الخاص بك جيدا؟ لا أعرف الكثير عن ذلك، ولكن هناك بعض خيارات التكوين التي قد يكون لها تأثير بعض التأثير.
  • تحسين خادم MySQL قد تعطيك بعض المعلومات المثيرة للاهتمام حول ذلك.

ومع ذلك، فإن أهم شيئين هي:

• لا تذهب إلى DB إذا كنت لا تحتاج إلى: ذاكرة التخزين المؤقت بقدر ما تستطيع!
• عندما يتعين عليك الذهاب إلى DB، استخدم الاستفسارات الفعالة: استخدم الفهارس؛ والملف الشخصي!

وماذا الآن؟

إذا كنت لا تزال تقرأ، فماذا يمكن تحسينه؟

حسنا، لا تزال هناك مجال للتحسينات ... قد تكون زوجين من الأفكار الموجهة نحو الهندسة المعمارية:

• قم بالتبديل إلى بنية N-Tier:
  • ضع mysql على خادم آخر (المستوى 2: واحد ل php؛ الآخر ل mysql)
  • استخدم عدة خوادم PHP (وتحميل الرصيد المستخدمين بين هؤلاء)
  • استخدم آلات أخرى للملفات الثابتة، مع WebServer أخف، مثل:
    • lighttpd.
    • أو nginx. - هذا واحد أصبح أكثر وأكثر شعبية، راجع للشغل.
  • استخدم عدة خوادم ل MySQL، عدة خوادم ل PHP، والعديد من الوكلاء العكسي أمام هؤلاء
  • بالطبع: تثبيت memcached. Daemons على أي خادم لديه أي كمية من ذاكرة الوصول العشوائي المجانية، واستخدامها لذاكرة التخزين المؤقت بقدر ما تستطيع / منطقية.
• استخدم شيئا "أكثر كفاءة" تلك أباتشي؟
  • أسمع أكثر وأكثر في كثير من الأحيان nginx., ، من المفترض أن تكون رائعة عندما يتعلق الأمر بمواقع PHP وعالية الحجم؛ لم أستخدمها أبدا بنفسي، لكنك قد تجد بعض المقالات المثيرة للاهتمام حولها على الشبكة؛
    • على سبيل المثال، PHP Performance III - تشغيل Nginx.
    • أنظر أيضا: PHP-FPM - مدير عملية FastCGI, ، التي يتم تجميعها مع PHP> = 5.3.3، ويتساءج مع Nginx.

حسنا، ربما بعض هذه الأفكار هي مبالغة قليلا في وضعك ^^
ولكن، لا يزال ... لماذا لا تدرسهم قليلا، فقط في حالة؟ ؛-)

وماذا عن كوهانا؟

كان سؤالك الأولي حول تحسين التطبيق الذي يستخدم كوهانا ... حسنا، لقد نشرت بعض الأفكار الحقيقية لأي تطبيق PHP... مما يعني أنهم صحيحون لكوهانا أيضا ؛-)
(حتى لو لم تكن محددة لها ^^)

قلت: استخدام ذاكرة التخزين المؤقت؛ يبدو أن كوهانا تدعم بعض التخزين المؤقت الاشياء (تحدثت عن ذلك بنفسك، لذلك لا شيء جديد هنا ...)
إذا كان هناك أي شيء يمكن القيام به بسرعة، جربه ؛-)

قلت أيضا أنك لا يجب أن تفعل أي شيء غير ضروري؛ هل هناك أي شيء تم تمكينه افتراضيا في Kohana أنك لا تحتاج؟
تصفح الشبكة، يبدو أنه هناك شيء على الأقل حول تصفية XSS؛ هل تحتاج ذلك؟

ومع ذلك، إليك بعض الروابط التي قد تكون مفيدة:

• كوهانا مناقشة عامة: التخزين المؤقت؟
• دعم المجتمع: تحسين موقع الويب: أقصى أداء موقع الويب باستخدام Kohana

خاتمة؟

وإلى أن تختتم، فكرة بسيطة:

• كم سيكلف شركتك أن تدفع لك 5 أيام؟ - بالنظر إلى أنه مبلغ معقول من الوقت للقيام ببعض التحسينات الرائعة
• كم سيكلف شركتك (دفع ل؟) خادم ثان، وصيانته؟
• ماذا لو كان لديك لتوسيع نطاق أكبر؟
  • كم سيكلف قضاء 10 أيام؟ أكثر؟ تحسين كل شيء ممكن من طلبك؟
  • وكم لمزيد من الخوادم؟

أنا لا أقول أنك يجب أن لا تتحسن: أنت بالتأكيد يجب أن!
ولكن الذهاب إلى تحسينات "سريعة" التي سوف تحصل على مكافآت كبيرة أولا: استخدام بعض ذاكرة التخزين المؤقت Opcode قد تساعدك على الحصول على 10 و 50 في المئة من تحميل وحدة المعالجة المركزية للخادم الخاص بك ... ويستغرق الأمر بضع دقائق فقط لإعداد ؛-) على الجانب الآخر، قضاء 3 أيام لمدة 2 في المئة. ..

أوه، و راجع للشغل: قبل القيام بأي شيء: ضع بعض الأشياء المراقبة في المكان, ، حتى تعرف ما هي التحسينات التي تم إجراؤها، وكيف!
بدون مراقبة، لن يكون لديك أي فكرة عن تأثير ما فعلته ... ولا حتى لو كان تحسين حقيقي أم لا!

على سبيل المثال، يمكنك استخدام شيء مثل rrdtool. + الصبار.
وإظهار رئيسك بعض الرسومات لطيفة مع انخفاض وحدة المعالجة المركزية 40٪ هو دائما رائع ؛-)

على أي حال، وتختتم حقا: استمتع!
(نعم، تحسين هو متعة!)
(Ergh، لم أكن أعتقد أنني سأكتب كثيرا ... آمل أن تكون بعض أجزاء هذا على الأقل مفيدة ... ويجب أن أتذكر هذه الإجابة: قد تكون مفيدة بعض أوقات أخرى ...)

Answer 2

يستخدم Xdebug. و Wincachegrind. أو WebCachegrind. إلى الملف الشخصي وتحليل تنفيذ التعليمات البرمجية البطيئة.

_{(مصدر: jokke.dk.)}

Answer 3

رمز الملف الشخصي مع Xdebug..

استخدام الكثير من التخزين المؤقت. إذا كانت صفحاتك ثابتة نسبيا، فقد تكون الوكيل العكسي أفضل طريقة للقيام بذلك.

Answer 4

Kohana خارج الصندوق بسرعة كبيرة، باستثناء استخدام كائنات قاعدة البيانات. إلى Quote Zombor "يمكنك تقليل استخدام الذاكرة من خلال ضمان استخدام كائن نتيجة قاعدة البيانات بدلا من صفائف النتيجة." هذا يجعل اختلاف أداء Hugee على موقع يتم انشهاره. لا تستخدم فقط الذاكرة، فهي تبطئ تنفيذ البرامج النصية.

أيضا - يجب عليك استخدام التخزين المؤقت. انا افضل memcache واستخدامه في طرازاتي مثل هذا:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

سيؤدي هذا أيضا إلى زيادة الأداء بشكل كبير. تقنيتين أعلاه تحسين أداء المواقع بنسبة 80٪.

إذا أعطيت بعض المعلومات الأخرى حول المكان الذي تعتقد أن عنق الزجاجة، فأنا متأكد من أننا يمكن أن نعطي بعض الأفكار الأفضل.

تحقق أيضا من Yslow (Google IT) لبعض نصائح الأداء الأخرى.

Answer 5

مرتبطة بدقة Kohana (ربما قمت بذلك بالفعل، أم لا):

في وضع الإنتاج:

1. تمكين التخزين المؤقت الداخلي (سيؤدي هذا فقط إلى مخبأ نتائج Kohana :: Find_File، ولكن هذا بالفعل يمكن أن يساعد كثيرا.
2. تعطيل profiler.

فقط 2 سنتات :)

Answer 6

أتفق تماما مع إجابات XDEBUG وتخزينها. لا تنظر إلى طبقة Kohana للتحسين حتى تعرف على أكبر سرعة وقصاصاتك.

سيقول لك Xdebug كنت تقضي معظم وقتك وتحديد "النقاط الساخنة" في التعليمات البرمجية الخاصة بك. احتفظ بمعلومات التنميط هذه حتى تتمكن من خط الأساس وقياس تحسينات الأداء.

مثال على المشكلة والحلول: إذا وجدت أنك تقوم ببناء كائنات باهظة الثمن من قاعدة البيانات في كل مرة، لا تتغير ذلك في كثير من الأحيان، ثم يمكنك إلقاء نظرة على التخزين المؤقت لهم مع Memcached أو آلية أخرى. كل هذه إصلاحات الأداء تستغرق بعض الوقت وإضافة تعقيد إلى نظامك، لذا تأكد من الاختناقات الخاصة بك قبل البدء في إصلاحها.