5.2الأداء: التخزين المؤقت (cache) وأوب.كاش (OPcache) وريديس (Redis)
الأساسي في 30 ثانية
- أوب.كاش (OPcache): البايت كود المترجم يُخزَّن مؤقتا — الترجمة مرة واحدة بدلا من كل طلب، ومكسب كبير شبه مجاني.
- التخزين المؤقت التطبيقي: تخزين النتائج المكلفة (ريديس (Redis)) لعدم إعادتها — وهو غالبا الرافعة الأعلى أثرا.
- قيسوا أولا: نمّطوا للعثور على الاختناق الحقيقي (غالبا القاعدة) — أبدا أي تحسين مبكر.
حالة مصغرة متسلسلة — رياد يسرّع متجره في قسنطينة
متجر رياد المهيكل في قسنطينة يتباطأ ساعات الذروة: صفحة الاستقبال تتأخر في الاستجابة. وبدلا من إعادة كتابة كل شيء، يقيس: أوب.كاش (OPcache) غير مفعّل في الإنتاج، ونفس استعلامات الفهرس تستدعي القاعدة بلا انقطاع. يفعّل أوب.كاش (OPcache) ويخزّن الفهرس مؤقتا. تتمة الحالة 5.1 — يحسّن رياد ما قاسه لا عشوائيا.
تتمة الحالة 5.1 — يطبق رياد القاعدة الذهبية: القياس أولا ثم التحسين.
1. أوب.كاش (OPcache): المكسب شبه المجاني
PHP مفسَّرة: عند كل طلب يترجم الخادم الشيفرة (إلى «بايت كود») قبل تنفيذها. وإعادة هذه الترجمة عند كل طلب بينما الشيفرة لا تتغير تبذير. فأوب.كاش (OPcache) امتداد (متاح عموما) يخزّن البايت كود المترجم مؤقتا: نترجم مرة ثم نعيد الاستعمال — مكسب أداء كبير وشبه مجاني. يتحقق رياد من أنه مفعّل ومضبوط جيدا في الإنتاج (وفي التطوير يُعطَّل أحيانا لرؤية التغييرات فورا). وتجلب نسخ PHP الحديثة فوق ذلك مكاسب جوهرية كبيرة.
المنعكس: تطبيق PHP في الإنتاج دون أوب.كاش (OPcache) أبطأ بكثير دون سبب — فهو تحسين القاعدة قبل أي آخر.
2. التخزين المؤقت التطبيقي وريديس (Redis)
الرافعة الأعلى أثرا في التطبيقات الحقيقية هي التخزين المؤقت (cache): تخزين نتائج مكلفة وقليلة التغير (استعلامات متكررة وحسابات ثقيلة وصفحات أو مقاطع وبيانات واجهات خارجية) لعدم إعادتها عند كل طلب. ولتخزين سريع ومشترك نستعمل غالبا ريديس (Redis) (أو Memcached) — تخزين في الذاكرة أي سريع جدا، ويصلح أيضا للجلسات وقوائم الانتظار. وتدمج الأطر (Laravel و Symfony) أنظمة تخزين سهلة الاستعمال بعدة مشغلات. يخزّن رياد الفهرس مؤقتا بمدة حياة قصيرة: فالطلبات المتكررة لم تعد تمس القاعدة.
قاعدة الاختيار: نخزّن ما إنتاجه مكلف ويحتمل تأخرا طفيفا — مع استراتيجية تحديث واضحة.
3. القاعدة والتنميط والمنهجية الجيدة
قاعدة البيانات غالبا الاختناق الحقيقي: استعلامات بطيئة أو غير مفهرسة، ومشكلة N+1 الشهيرة (شائعة مع ORM: استعلام لكل عنصر من قائمة بدلا من واحد — وتُصحَّح بالتحميل المجمع للعلاقات «eager loading»). وفهرسة الأعمدة المطلوبة وتحسين الاستعلامات له غالبا الأثر الأكبر. والمنهجية الغالبة على الكل: التنميط — القياس قبل التحسين لتحديد الاختناقات الحقيقية بدلا من التحسين على العمى. ينمّط رياد قبل لمس الشيفرة: فالبطء كان من القاعدة لا من حلقاته.
مبدأ عابر: لا تحسين مبكر. شيفرة صحيحة وواضحة أولا، والقياس عند وقوع مشكلة، ثم تحسين مستهدَف. والتحسين المبكر جدا يضيع الوقت ويعقد دون فائدة.
🔎 مثال ملموس — رياد يخزّن الفهرس مؤقتا
التحقق من أوب.كاش (OPcache) ثم تخزين نتيجة مكلفة مؤقتا.
query('SELECT id, nom, prix FROM produits')->fetchAll(PDO::FETCH_ASSOC);
file_put_contents($fichier, json_encode($lignes));
return $lignes;
}القراءة: نتحقق من المكسب المجاني (أوب.كاش (OPcache)) ثم نتجنب إعادة المكلف (تخزين مؤقت بمدة حياة).
الدرس: في الإنتاج سيعيش هذا التخزين في ريديس (Redis) — مشتركا بين كل العمليات.
مفردات القسم
- أوب.كاش (OPcache)
- امتداد يخزّن بايت كود PHP المترجم مؤقتا، مترجما مرة واحدة.
مثال بسيط: يفعّله رياد في الإنتاج: انتهت إعادة الترجمة عند كل طلب.
ما ليس كذلك: تخزين مؤقت لصفحات HTML.
رد فعل: هل أوب.كاش (OPcache) مفعّل في إنتاجي ؟
- التخزين المؤقت (cache)
- تخزين النتائج المكلفة لعدم إعادة حسابها كل مرة.
مثال بسيط: فهرس رياد يُقدَّم من التخزين لا من القاعدة بعد.
ما ليس كذلك: إضافة خوادم قبل التخزين.
رد فعل: أي الاستعلامات تعود بلا انقطاع متماثلة ؟
- ريديس (Redis)
- تخزين في الذاكرة سريع، ويستعمل غالبا تخزينا مؤقتا مشتركا.
مثال بسيط: يضع رياد فيه الفهرس بمدة حياة قصيرة.
ما ليس كذلك: قاعدة البيانات الرئيسية نفسها.
رد فعل: هل تحتمل هذه النتيجة تأخرا طفيفا ؟
- مشكلة N+1
- استعلام لكل عنصر من قائمة بدلا من استعلام مجمع واحد.
مثال بسيط: يحمّل رياد آراء 50 منتجا دفعة واحدة لا في 50 استعلاما.
ما ليس كذلك: نقص ذاكرة على الخادم.
رد فعل: كم استعلاما ينطلق لعرض هذه القائمة ؟
- التنميط
- القياس لتحديد الاختناقات الحقيقية قبل التحسين.
مثال بسيط: يكتشف رياد أن البطء من استعلام غير مفهرس.
ما ليس كذلك: تحسين حلقاته بالحدس.
رد فعل: هل قست قبل لمس الشيفرة ؟
في التطبيق — تحسين تطبيق PHP
- تحققوا من أن أوب.كاش (OPcache) مفعّل ومضبوط جيدا (لا سيما في الإنتاج) — مكسب أداء كبير شبه مجاني (بايت كود مترجم مخزَّن مؤقتا).
- خزّنوا مؤقتا نتيجة مكلفة (استعلاما متكررا) — في الذاكرة أو مع ريديس (Redis) — وقيسوا المكسب؛ واستعملوا نظام التخزين في إطار.
- حسّنوا القاعدة: فهرسوا الأعمدة المطلوبة ورصدوا مشكلة N+1 وصححوها (التحميل المجمع للعلاقات) — وهو غالبا الأثر الأكبر.
- نمّطوا لتحديد الاختناقات الحقيقية قبل التحسين (القياس قبل التحسين)؛ ولا تحسّنوا مبكرا (شيفرة صحيحة أولا).
نص جاهز للقول — تبرير تحسين
«في قسنطينة، يتباطأ متجرنا ساعات الذروة. وقد قست: أوب.كاش (OPcache) غير مفعّل في الإنتاج واستعلامات الفهرس تشبع القاعدة. أقترح خطوتين مستهدفتين: تفعيل أوب.كاش (OPcache) وتخزين الفهرس مؤقتا بمدة حياة قصيرة. نعيد القياس بعدها، ولا نمس البنية إلا إذا برر القياس ذلك.»
يُقال للمسؤول لاعتماد تحسين مقيس بدلا من إعادة كتابة على العمى.
نموذج للنسخ واللصق — بطاقة تشخيص الأداء
الأداء — تشخيص
العرَض: _______________ (متى ؟ ___)
أوب.كاش (OPcache): مفعّل في الإنتاج ؟ ___
القياس: زمن الاستجابة ___ · أبطأ استعلام ___
الاختناق المشتبه: غياب التخزين / القاعدة (الفهرس و N+1) / الشيفرة: ___
الإجراء المستهدَف: أوب.كاش / تخزين ريديس (Redis) / فهرس / تحميل مجمع: ___
إعادة القياس: قبل ___ ← بعد ___ · المكسب: ___فردي / ميزانية صغيرة
رياد وحده: أوب.كاش (OPcache) + تخزين ملفي للصفحات المكلفة يكفي — وسيأتي ريديس (Redis) عندما يبرر الحجم ذلك.
شركة صغيرة جدا / فريق مصغر
فهرسوا الاستعلامات البطيئة أولا: وهو غالبا المكسب الأسرع دون بنية جديدة.
شركة صغيرة ومتوسطة في قسنطينة
يخطط رياد للقياسات ساعات الذروة في قسنطينة، مع بروتوكول إعادة قياس بعد كل تغيير.
فريق يبدأ
ثنائي: أحدهما ينمّط بينما يجهّز الآخر التخزين المؤقت؛ ومراجعة مشتركة للقياسات قبل أي تحسين.
✓ ممارسات جيدة
- تحققوا من أوب.كاش (OPcache) في الإنتاج قبل أي تحسين آخر (المكسب المجاني).
- خزّنوا النتائج المكلفة مؤقتا؛ وفهرسوا وصححوا N+1.
- قيسوا (نمّطوا) قبل التحسين، واستهدفوا الاختناقات الحقيقية.
✗ أخطاء شائعة
- تحسين الحلقات بالحدس دون قياس (فالاختناق في مكان آخر).
- نسيان أوب.كاش (OPcache) في الإنتاج (بطء دون سبب).
- التخزين المؤقت دون مدة حياة ولا استراتيجية تحديث (بيانات متقادمة).
النقاط الأساسية
- أوب.كاش (OPcache): يخزّن بايت كود PHP المترجم مؤقتا (الترجمة مرة واحدة بدلا من كل طلب) — مكسب كبير شبه مجاني. يُفعَّل ويُضبَط لا سيما في الإنتاج.
- التخزين المؤقت (غالبا الأعلى أثرا): تخزين النتائج المكلفة (استعلامات متكررة وحسابات وصفحات) لعدم إعادتها؛ وريديس (Redis) (تخزين في الذاكرة سريع). وتدمج الأطر التخزين.
- تحسين القاعدة (غالبا الاختناق الحقيقي): الفهرسة وتحسين الاستعلامات وتصحيح N+1 (التحميل المجمع). والتنميط (القياس) قبل التحسين (القاعدة الذهبية).
- لا تحسين مبكر: شيفرة صحيحة وواضحة أولا، والقياس عند وقوع مشكلة، ثم تحسين مستهدَف. والتحسين المبكر جدا = وقت ضائع + تعقيد عديم الفائدة.
تحدي 48 ساعة — طبّق غدا
املؤوا بطاقة التشخيص لـ بطء حقيقي واحد في تطبيقكم: أوب.كاش (OPcache) متحقق منه والقياس والاختناق المشتبه — دون لمس الشيفرة بعد.
- أستطيع شرح أوب.كاش (OPcache) مقابل التخزين التطبيقي في جملة.
- بطاقة تشخيصي (القياس قبل التحسين) مملوءة.
- أعرف لماذا القاعدة هي المشتبه الأول.
أسئلة شائعة
ما أوب.كاش (OPcache) والتخزين المؤقت وكيف نحسّن أداء تطبيق PHP ؟
آليتان مختلفتان ومتكاملتان. يحل أوب.كاش (OPcache) تبذيرا خاصا بـ PHP: إعادة ترجمة الشيفرة عند كل طلب. فيخزّن البايت كود المترجم مؤقتا — نترجم مرة ونعيد الاستعمال — مكسب كبير شبه مجاني، يُفعَّل لا سيما في الإنتاج. ويحل التخزين التطبيقي تبذيرا آخر: إعادة عمليات مكلفة (استعلامات متكررة وحسابات وصفحات) بينما النتيجة قليلة التغير. نخزّن النتيجة (غالبا في ريديس (Redis) في الذاكرة وسريع جدا) بمدة حياة. ويُضاف تحسين القاعدة (الفهرس وتصحيح N+1 — غالبا الاختناق الحقيقي) والتنميط: القياس للتحسين حيث يهم، أبدا على العمى.
كيف أعرف متى وماذا أحسّن دون الوقوع في التحسين المبكر ؟
القاعدة الذهبية: لا تحسّنوا قبل مشكلة حقيقية ومقيسة. فالتحسين المبكر يضيع الوقت ويعقد الشيفرة ويخطئ الاختناق الحقيقي (الحدس يخدع). المنهجية: شيفرة صحيحة وواضحة أولا والقياس (التنميط وأزمنة الطلبات) عند وقوع مشكلة وتحسين مستهدَف حيث يهم وإعادة القياس لتأكيد المكسب. فمعظم الشيفرة لا يحتاج تحسينا: جزء صغير يركّز جوهر الكلفة — والقياس يعيّنه.
ما أول منعكس للأداء في تطبيق PHP في الإنتاج ؟