قم بتحسين الطبقة تلو الأخرى — كل طبقة تمتص الحمل قبل وصوله إلى الطبقة التالية. الهدف هو خدمة معظم الطلبات من ذاكرة التخزين المؤقت والحفاظ على PHP وقاعدة البيانات يقومان بأقل قدر من العمل.
قم بتحديد حجم مجموعة بناءً على ذاكرة الوصول العشوائي (RAM) الخاصة بك، وقم بتفعيل حتى يتم ترجمة PHP مرة واحدة، وليس مع كل طلب:
; php-fpm pool: cap workers so you don't exhaust RAM
; pm.max_children = (available RAM for PHP) / (avg process size, ~50MB)
pm = dynamic
pm.max_children = 40 ; hard ceiling on concurrent PHP workers
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; recycle workers to avoid memory leaks
; OPcache: cache compiled bytecode in memory
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; skip file-stat checks in prod (flush on deploy)
إذا كان max_children مرتفعًا جدًا فستقوم بالتبديل والتعطل؛ وإذا كان منخفضًا جدًا فستنتظر الطلبات في الطابور (502s تحت الحمل).
هذا التدرج الطبقي يعني أن نقرة الصفحة الرئيسية يمكن أن تعود من الحافة أو ذاكرة الصفحة دون لمس PHP أو قاعدة البيانات على الإطلاق.
قم بتفعيل slow query log للعثور على المشكلات، وأضف indexes للاستعلامات المخصصة، وراجع autoloaded options (wp_options مع autoload = yes يحمل على كل طلب — البيانات المحملة تلقائيًا المنتفخة تبطئ كل شيء). أخيرًا، قلل من تضخيم المكون الإضافي: كل مكون إضافي يضيف استعلامات وعمل PHP، لذا قم بإزالة الاستخدامات غير المستخدمة.
طلب WordPress ثقيل على PHP وقاعدة البيانات بشكل افتراضي، لذا فإنه ينهار تحت الحركة بدون ضبط. تخزين الطبقات المؤقتة (OPcache → object cache → page cache → CDN) بالإضافة إلى حجم PHP-FPM المناسب وقاعدة بيانات سليمة يسمح لخادم واحد بالتعامل مع حركة أكثر بكثير — ويبقيها قائمة أثناء الارتفاعات.