إعداد Redis لتخزين كائنات WordPress على VPS

ما الذي يفعله التخزين المؤقت للكائنات باستخدام Redis في WordPress

يخزّن التخزين المؤقت للكائنات باستخدام Redis في WordPress نتائج استعلامات قاعدة البيانات في الذاكرة، لذلك يقرأ الطلب التالي هذه النتائج من Redis بدلاً من طلبها من MySQL مرة أخرى. يحتوي WordPress أساساً على تخزين مؤقت للكائنات ضمن النواة، WP_Object_Cache، لكنه يعمل في ذاكرة PHP ويُحذف عند انتهاء الطلب. يستبدل ملف drop-in هذا التخزين المؤقت بآخر يتصل بـRedis، لذلك يبقى التخزين المؤقت من طلب إلى آخر.

لا يعني التخزين المؤقت للكائنات التخزين المؤقت للصفحات، وهذا الفرق يحدد ما إذا كان هذا الدليل يستحق وقتك. يخزّن التخزين المؤقت للصفحات HTML النهائي لعنوان URL، ويعيد تقديمه من دون تشغيل PHP على الإطلاق. وهذا أسرع من أي إجراء يمكن أن ينفذه Redis، كما أنه يعمل للزوار الذين لم يسجّلوا الدخول. عند تسجيل أي شخص الدخول، أو وضعه عنصراً في عربة التسوق، أو فتحه لوحة الإدارة، يتراجع التخزين المؤقت للصفحات، ويشغّل WordPress الطلب كاملاً: التهيئة، والإضافات، والاستعلامات. يجعل التخزين المؤقت للكائنات هذا الطلب أرخص. وهو الأداة المناسبة لحركة المرور التي لا يستطيع التخزين المؤقت للصفحات التعامل معها: الجلسات التي سجّل أصحابها الدخول، وعربات التسوق، وإتمام الشراء، وwp-admin. في متجر WooCommerce، يشكّل ذلك معظم حركة المرور المكلفة.

يمكن استخدام النوعين معاً، وكلاهما مناسب للموقع المزدحم. حدّد المشكلة التي تحاول إصلاحها بوضوح. يحصل موقع تعريفي يضم قراء مجهولين على معظم سرعته من التخزين المؤقت للصفحات، ولن تؤدي إضافة Redis إليه إلى تغيير كبير.

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

ما تحتاج إليه أولاً

• خادم VPS يعمل بنظام Linux، مع shell وsudo. لا تحتاج إلى لوحة تحكم.
• WordPress يُقدَّم عبر PHP-FPM، مثل مكدس LAMP على Ubuntu 24.04.
• WP-CLI مثبت على الخادم. لكل خطوة هنا مقابل في شاشة الإدارة، لكن إصدار shell أسرع.
• Redis على الجهاز نفسه الذي يشغّل PHP. الهدف الأساسي هو تقليل زمن الاستجابة، وتُبطل قفزة الشبكة هذه الفائدة.

الأوامر أدناه مخصّصة لـUbuntu 24.04 مع PHP 8.3 ومستخدم الويب www-data. عدّل إصدار PHP والمستخدم ليتوافقا مع خادمك. شغّل أوامر wp من مجلد WordPress الذي يحتوي على wp-config.php.

تثبيت Redis وإضافة PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

من المفترض أن يعرض redis-cli ping القيمة PONG. إذا طبع Could not connect to Redis at 127.0.0.1:6379: Connection refused، فهذا يعني أن الخادم لا يعمل، لذا اقرأ systemctl status redis-server قبل المتابعة.

php-redis هو PhpRedis، وهي إضافة C من PECL. وهي أسرع من Predis، المكتوبة بالكامل بلغة PHP، ويستخدمها المكوّن الإضافي تلقائياً عند توفرها. يحمّل PHP-FPM الإضافات عند بدء التشغيل، لذلك لن تصبح الإضافة الجديدة مرئية قبل إعادة تشغيل مجموعة العمليات.

sudo systemctl restart php8.3-fpm
php -m | grep redis

انتبه إلى الفحص الأخير: يعرض php -m الوحدات التي يحمّلها PHP من سطر الأوامر، وقد يحمّل FPM مجموعة مختلفة. الفحص الحاسم هو تشخيص المكوّن الإضافي نفسه، الوارد أدناه.

اعتباراً من August 2026، توفّر Ubuntu 24.04 الحزمة Redis 7.0.15، وهي مناسبة لذاكرة التخزين المؤقت للكائنات. إذا أردت إصداراً حديثاً، فتنشر Redis مستودع APT الخاص بها.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

إذا كان توزيعك يوفّر Valkey، وهو الفرع الذي بدأ بعد تغيير الترخيص في 2024، فهو يستخدم البروتوكول نفسه، وينطبق كل ما يلي عليه دون تغيير.

اربط Redis بحيث لا يتمكن أي طرف آخر من الوصول إليه

لا يملك Redis كلمة مرور افتراضية. يمكن لأي طرف يستطيع فتح اتصال بالمنفذ 6379 قراءة كل قيمة مخزنة مؤقتاً وتنفيذ FLUSHALL. تُكتشف النسخ المكشوفة على الإنترنت بواسطة أدوات الفحص خلال ساعات، لذلك يجب ضبط إعدادات الشبكة قبل التحسينات الأخرى.

افتح /etc/redis/redis.conf وتحقق من وجود السطور التالية:

bind 127.0.0.1 -::1
protected-mode yes

ثم تحقق مما يستمع فعلياً، لأن ملف الإعدادات يعبّر عن الإعداد المقصود، بينما ss هو الدليل الفعلي.

sudo ss -lntp | grep 6379

هذه هي النتيجة المطلوبة في 127.0.0.1:6379. تعني 0.0.0.0:6379 أن Redis يستجيب على الواجهة العامة. أصلح السطر bind ثم أعد التشغيل.

عندما يعمل PHP وRedis على الخادم نفسه، يكون مقبس Unix أفضل من TCP عبر loopback. لا تمر البيانات عبر مكدس TCP، ويُحدَّد الوصول بواسطة أذونات الملف بدلاً من قاعدة جدار ناري قد تغيّرها لاحقاً.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

يملك المستخدم والمجموعة redis المقبس، لذلك يجب إضافة مستخدم الويب إلى هذه المجموعة.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

يجب أن يعرض ذلك أيضاً PONG. تعني Could not connect to Redis at /run/redis/redis-server.sock: Permission denied أن المجموعة لم تُطبَّق. تحقق من id www-data، وتذكّر أن عملية PHP-FPM قيد التشغيل تحتفظ بالمجموعات التي كانت لديها عند بدء التشغيل، ولذلك أُدرجت إعادة التشغيل. أبقِ TCP مفعّلاً إلى أن تتأكد من عمل المقبس، وإلا فقد يؤدي خطأ مطبعي إلى تعطيل مساري الوصول معاً.

كم مقدار الذاكرة التي ينبغي تخصيصها لـRedis؟

استخرج الرقم من الخادم نفسه. ينمو Redis من دون maxmemory حتى تنفد ذاكرة النواة، وينهي قاتل OOM إحدى العمليات، وغالباً ما تكون العملية الأكبر. في خادم WordPress، تكون هذه العملية غالباً MySQL. يعرض journalctl -k | grep -i "out of memory" عملية الإنهاء بعد حدوثها، لكن الموقع يكون قد توقف بحلول ذلك الوقت.

ابدأ بإجمالي ذاكرة RAM ثم اطرح منه الاحتياجات الأخرى. يحجز MySQL أو MariaDB مقدار innodb_buffer_pool_size، إضافة إلى المخازن المؤقتة لكل اتصال. وتبلغ تكلفة PHP-FPM مقدار pm.max_children مضروباً في الحجم المقيم الفعلي لعامل واحد، وهو يتراوح غالباً بين 64 MB و128 MB في المواقع التي تحتوي على عدد كبير من الإضافات. تحتاج النواة وخادم الويب إلى بضع مئات من الميغابايت. ما يتبقى هو الحد الأقصى المتاح، ويحصل Redis على جزء منه.

قِس الآن بدلاً من التخمين. بعد يوم من حركة المرور الفعلية:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

إذا ظل used_memory_human أقل بكثير من الحد الذي حددته، فاخفض الحد وأعد الذاكرة إلى MySQL، إذ سيستخدمها بكفاءة أكبر. وإذا بلغ الحد وظل عنده وواصل evicted_keys الارتفاع طوال اليوم، فارفعه. اضبط القيمة في /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

يطبّق redis-cli config set maxmemory 256mb التغيير فوراً، لكنه يُنسى عند إعادة التشغيل التالية. وهذا هو الفخ نفسه الموجود في sysctl -w المجرد. حرّر الملف، ثم sudo systemctl restart redis-server، ثم اقرأ القيمة مجدداً. من المفيد وضع حد ثانٍ: يوقف حد MemoryMax على وحدة systemd خدمة Redis التي أُسيء إعدادها من إسقاط الخادم بأكمله. اضبطه أعلى من maxmemory، ولا تجعله مساوياً له، لأن حد cgroup ينهي العملية بدلاً من إخلاء مفتاح. إذا كان Redis يعمل في حاوية إلى جانب WordPress، فضَع الرقم نفسه ضمن حدود الذاكرة في ملف Compose، ويقود المنطق نفسه اختيار تشغيل قاعدة البيانات في Docker أو على الخادم المضيف.

اختر سياسة الإخلاء عمداً

تستخدم Redis الجديدة الإعداد الافتراضي noeviction. تحقّق من إعدادك:

redis-cli config get maxmemory-policy

عند استخدام noeviction، يتوقف المثيل الممتلئ عن قبول عمليات الكتابة ويُرجع الرسالة التالية:

(error) OOM command not allowed when used memory > 'maxmemory'.

هذا السطر هو أسوأ نمط فشل في هذا الدليل، لأن الموقع لا يتوقف. بل يصبح أبطأ. تفشل كل عملية كتابة إلى ذاكرة التخزين المؤقت، لذلك يعود WordPress إلى قاعدة البيانات لجلب القيمة، ثم يحاول تخزينها مرة أخرى في الطلب التالي ويفشل مجدداً. يدفع الموقع الآن تكلفة كل عمليات قاعدة البيانات الأصلية، إضافةً إلى رحلة ذهاب وإياب إلى Redis لكل مفتاح. لا يخبرك أي شيء في لوحة إدارة WordPress بأن هذا يحدث. تظهر هذه السلسلة النصية في سجل أخطاء PHP، لذلك ابحث عن OOM command not allowed باستخدام grep عندما يصبح الموقع أبطأ بعد إضافة ذاكرة تخزين مؤقت.

يُعد allkeys-lru الإعداد الافتراضي المناسب هنا. تحذف Redis المفتاح الأقل استخداماً مؤخراً عندما تضيق مساحة الذاكرة، وهذا هو المطلوب تحديداً لذاكرة تخزين الكائنات، لأن كل قيمة فيها نسخة من بيانات لا تزال موجودة في MySQL. يؤدي فقدان مفتاح إلى استعلام واحد. أما رفض عملية الكتابة فيؤدي إلى تنفيذ كل الاستعلامات، في كل طلب، إلى أن يلاحظ أحد ذلك.

تجنب سياسات volatile-* لهذا الاستخدام. فهي تراعي فقط المفاتيح التي لها مدة انتهاء، وتوثّق Redis أنها تتصرف مثل noeviction عندما لا يكون لأي مفتاح مدة انتهاء. يخزّن WordPress معظم إدخالات ذاكرة تخزين الكائنات من دون TTL، لذلك قد تمتلئ volatile-lru في ذاكرة تخزين الكائنات وتبدأ برفض عمليات الكتابة. يُعد allkeys-lfu بديلاً مناسباً إذا كانت حركة المرور تصل إلى مجموعة صغيرة من المفاتيح بكثرة، لأنها تُخلي المفاتيح وفق معدل تكرار استخدامها بدلاً من حداثة استخدامها. اختر سياسة واحدة عن قصد، وسجّل سبب اختيارها.

الإبقاء على الاستمرارية معطّلة ما لم يكن لديك سبب لتفعيلها

يفعّل redis.conf المضمّن لقطات RDB عبر أسطر مثل save 900 1، ويُبقي ملف الإلحاق فقط معطّلاً. بالنسبة إلى ذاكرة تخزين مؤقت للكائنات فقط، لا تقدّم اللقطات أي فائدة. فالبيانات قابلة لإعادة الإنشاء بحكم تعريفها، وستكون ذاكرة التخزين المؤقت التي تُستعاد من ملف عمره عشرون دقيقة مجموعة من القيم القديمة التي سيثق بها WordPress.

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

Can't save in background: fork: Cannot allocate memory

ويظهر غالباً هذا التحذير عند بدء التشغيل أيضاً، وهو يعني أن Redis يتوقع احتمال فشل عملية الإنشاء لاحقاً:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

لتعطيل اللقطات، عيّن جدول حفظ فارغاً في /etc/redis/redis.conf، ثم أعد التشغيل وتأكد من أن القيمة عادت فارغة.

save ""

sudo systemctl restart redis-server
redis-cli config get save

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

Install the plugin, and understand the drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable prints Object cache enabled. on success. What it actually does is copy wp-content/plugins/redis-cache/includes/object-cache.php to wp-content/object-cache.php. That copy is the drop-in, and the drop-in is the part that does the work. WordPress loads wp-content/object-cache.php very early, before any plugin code runs, which is how the cache is available for the whole request. An active plugin with no drop-in in place caches nothing.

The failure messages tell you which half broke. Object cache could not be enabled. means the copy failed, so wp-content is not writable by the user running WP-CLI. A foreign object cache drop-in was found. means another caching plugin already owns that filename, and the fix is wp redis update-dropin. A message ending Redis server is unreachable: followed by the client error means the connection settings are wrong, so go back to redis-cli ping.

If the copy failed on permissions, place it by hand and give it to the web user.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Removing the plugin does not remove the drop-in. Run wp redis disable first, which prints Object cache disabled. and deletes the file. Delete the plugin directory while the drop-in stays behind and the site keeps running old cache code with no plugin to update it.

إعدادات الاتصال في wp-config.php

أضف هذه الأسطر قبل السطر الذي يقرأ /* That's all, stop editing! */، لأن الثوابت المعرّفة بعده تأتي متأخرة جداً.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

بالنسبة إلى Unix socket، اضبط المخطط والمسار. عندئذٍ يتم تجاهل المضيف والمنفذ.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

يفرض WP_REDIS_MAXTTL مدة انتهاء صلاحية لكل مفتاح، بالثواني. لا تحتاج إليه مع allkeys-lru، وهو مفيد إذا أردت وضع حد أقصى صارماً لمدة بقاء قيمة مخزّنة مؤقتاً قديمة.

Redis واحد، عدة مواقع: البادئات وقواعد البيانات

يوفّر Redis ست عشرة قاعدة بيانات مرقّمة افتراضياً، وتحتوي كل قاعدة على مساحة مفاتيح مسطّحة واحدة. إذا وُجّه تثبيتا WordPress إلى قاعدة البيانات 0 من دون بادئة، فسيكتبان أسماء المفاتيح نفسها في المساحة نفسها. لذلك قد يقرأ أحد الموقعين خيارات الموقع الآخر ويستخدمها. امنح كل موقع بادئة خاصة به.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

تفصل البادئة أسماء المفاتيح. ويفصل فهرس قاعدة البيانات مساحات المفاتيح، وهذا مهم عند تنفيذ عملية التفريغ: إفراغ أحد الفهارس لا يؤثر في الفهارس الأخرى. كما يوثّق المكوّن WP_REDIS_SELECTIVE_FLUSH، الذي يحذف المفاتيح المطابقة لبادئتك فقط بدلاً من حذف قاعدة البيانات بأكملها، لكن ذلك يتطلب البحث عن هذه المفاتيح.

ما لا تفصله البادئات والفهارس هو الذاكرة. ينطبق maxmemory وسياسة الإخلاء على المثيل بأكمله، لذلك قد يدفع موقع نشط مفاتيح موقع قليل النشاط إلى الإخلاء، ولن يبلّغ أيٌّ منهما عن ذلك. تحتاج المواقع التي يجب ألا يؤثر بعضها في بعض إلى مثيلات Redis منفصلة، ولكل مثيل socket وحدّ خاص به.

أبقِ بيئة الاختبار خارج ذاكرة التخزين المؤقت للإنتاج

يكون موقع الاختبار عادةً نسخة من ملفات الإنتاج وقاعدة بياناته، ما يعني أنه نسخة من wp-config.php تستخدم البادئة نفسها وفهرس قاعدة البيانات نفسه. إذا وجّهته إلى Redis نفسه، فسيكتب مفاتيح الإنتاج بقيم بيئة الاختبار. وقد يظهر سعر تجريبي أو خيار مُعدَّل على الموقع الفعلي من دون نشر أو أثر في السجلات.

حدّد قيمة مميِّزة لكل بيئة يدوياً. في ملف wp-config.php الخاص ببيئة الاختبار:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

والأفضل من ذلك أن تمنح بيئة الاختبار نسخة Redis مستقلة، أو ألا تستخدم ذاكرة تخزين مؤقت للكائنات إطلاقاً. يعمل define( 'WP_REDIS_DISABLED', true ); على تعطيل ذاكرة التخزين المؤقت أثناء التشغيل، مع إبقاء drop-in في مكانه. وهذه أيضاً أسرع طريقة لإثبات ما إذا كان الخطأ ناتجاً عن ذاكرة التخزين المؤقت أم لا.

كانت البرامج التعليمية الأقدم تضبط WP_CACHE_KEY_SALT لهذا الغرض. يوضح ملف readme الخاص بالإضافة أن هذا الثابت deprecated واستُبدل بـ WP_REDIS_PREFIX، لذا استخدم الاسم الجديد.

تحقّق منه بدلاً من الوثوق به

ابدأ بأدوات التشخيص الخاصة بالإضافة.

wp redis status

السطر الأهم هو Drop-in. يعني Drop-in: Valid أن WordPress يحمّل ملف هذه الإضافة. ويعني Drop-in: Not installed أن النسخ لم يحدث قط، وأن الموقع لا يملك ذاكرة تخزين مؤقت دائمة، مهما بدت شاشة الإدارة خضراء. يعرض Status الاتصال، ويسمّي Client الامتداد المستخدم. وهنا تتأكد من استخدام PhpRedis بدلاً من Predis.

ثم اسأل نواة WordPress مباشرة، لأنها لا تعتمد على ما تعتقده الإضافة.

wp eval 'var_dump( wp_using_ext_object_cache() );'

يعني bool(true) أن النواة تتصل بذاكرة تخزين مؤقت للكائنات خارجية.

ثم أثبت وصول المفاتيح باستخدام البادئة التي ضبطتها.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

يُعد ارتفاع dbsize أثناء تنقلك في الموقع دليلاً على ذلك. إذا كان عدد المفاتيح صفراً مع وجود drop-in صالح، فهذا يعني أن الاتصال يفشل بصمت، أو أن البادئة ليست البادئة التي تظنها.

أخيراً، راجع المقاييس التي يحسبها Redis لك.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

نسبة الوصول إلى البيانات المخزنة مؤقتاً هي keyspace_hits / (keyspace_hits + keyspace_misses)، وتعرض وثائق Redis هذه الصيغة. اقرأها مع تنبيهين. تغطي العدادات المثيل بالكامل منذ آخر إعادة تشغيل له، لذلك فهي تخلط بين كل موقع وكل تطبيق يتشاركان المثيل. كما أن النسبة بعد عملية flush أو إعادة التشغيل مباشرة لا تعني شيئاً، لأن ذاكرة التخزين المؤقت ما زالت تمتلئ. اتركها تعمل خلال يوم اعتيادي من حركة الشبكة.

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

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

نفّذ ذلك باستخدام حاوية ملفات تعريف ارتباط مسجّل الدخول، عدة مرات، مع تعطيل ذاكرة التخزين المؤقت (WP_REDIS_DISABLED) ثم تفعيلها. الفرق بين النتيجتين هو نتيجتك.

عندما يجعل Redis موقع WordPress أبطأ

تحدث المشكلة الأكبر عند امتلاء instance مع استخدام policy غير مناسبة، وقد غطيناها أعلاه: OOM command not allowed when used memory > 'maxmemory'. في السجل، مع تحمّل الموقع تكلفة قاعدة البيانات وذاكرة التخزين المؤقت معاً.

المشكلة الثانية هي تشغيل Redis على مضيف آخر. يجري WordPress مئات الاستدعاءات لذاكرة تخزين الكائنات ضمن الطلب الواحد. إذا أجرى الطلب 500 استدعاء، وكانت تكلفة كل رحلة ذهاب وإياب 1 ms، فهذا يعني نصف ثانية من الانتظار لا يحتاج إليها socket محلي. أبقِ Redis على الخادم نفسه، أو على شبكة خاصة ذات زمن استجابة أقل من millisecond واحد.

المشكلة الثالثة هي ضخامة جدول options المحمّلة تلقائياً، وهذا شائع في المواقع القديمة. يخزّن WordPress جميع options المحمّلة تلقائياً في مفتاح واحد، لذلك تعبر ميغابايتات منها الاتصال في كل طلب. قِس حجمها:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

أضاف WordPress 6.6 قيماً جديدة إلى autoload، لذلك فإن الاستعلام الأقدم الذي يطابق 'yes' فقط يقلّل من الحجم الفعلي في التثبيتات الحديثة. أي حجم يتجاوز megabyte واحداً يمثل مشكلة يجب إصلاحها في جدول options، لا في Redis.

يؤدي إعادة التشغيل إلى إفراغ كل شيء، لذلك تكون الدقائق التي تلي systemctl restart redis-server مليئة بعمليات cache miss وبعمل قاعدة البيانات. أعد التشغيل عندما تكون حركة المرور منخفضة. كما أن object cache لا يمنع تشغيل wp-cron.php عند تحميل صفحات الزوار، وهذا مصدر مستقل للطلبات البطيئة: انقل WP-Cron إلى مهمة cron فعلية في النظام أثناء معالجة هذه المشكلة.

التنظيف

نفّذ التفريغ بعد نشر يغيّر الخيارات أو شيفرة السمة باستخدام wp cache flush. شغّل wp redis update-dropin بعد تحديث إضافة إذا لم تُحدِّث ملف drop-in نفسه، لأن استخدام ملف drop-in من إصدار أقدم من الإضافة مع إصدار أحدث منها يسبب سلوكاً غير اعتيادي فعلاً. راقب خادماً قيد التشغيل باستخدام redis-cli --stat، إذ يطبع سطراً واحداً كل ثانية. يطبع redis-cli monitor كل أمر وينهك المعالج فعلياً على المثيل المزدحم، لذلك استخدمه لبضع ثوانٍ أثناء إعادة إنتاج المشكلة، ثم أوقفه.

هناك رقم أخير يستحق معرفته: يعرض redis-cli info clients قيمة connected_clients. يحتفظ PHP-FPM باتصال واحد لكل عامل، لذلك ينبغي أن يتوافق هذا الرقم مع pm.max_children، لا أن يتجاوزه بعشرة أضعاف. إذا حدث ذلك، فهناك شيء يفتح اتصالات ولا يغلقها.

FAQ

هل ما زلت أحتاج إلى ذاكرة التخزين المؤقت للصفحات إذا كنت أستخدم ذاكرة Redis المؤقتة للكائنات؟

نعم، لحركة المرور المجهولة. تقدّم ذاكرة التخزين المؤقت للصفحات HTML مخزناً دون تشغيل PHP، وهذا يكون دائماً أقل تكلفة من تشغيل WordPress مع ذاكرة مؤقتة للكائنات مهيّأة مسبقاً. تتولى ذاكرة الكائنات الطلبات التي يجب على ذاكرة الصفحات تخطيها: المستخدمون الذين سجّلوا الدخول، وسلال التسوق، وإتمام الشراء، وwp-admin. في المتجر أو موقع العضويات، يستحق تشغيل الذاكرتين. أما في موقع لا يسجّل زواره الدخول مطلقاً، فتنجز ذاكرة الصفحات معظم العمل.

ما مقدار الذاكرة التي ينبغي تخصيصها لـ Redis من أجل WordPress؟

احسبه استناداً إلى خادمك، بدلاً من نسخ قيمة جاهزة. خذ إجمالي الذاكرة RAM، واطرح منه مخزن MySQL المؤقت ومخازن كل اتصال، ثم اطرح pm.max_children مضروباً في الحجم المقيم لعامل PHP-FPM واحد، واطرح بضع مئات من الميغابايتات للنواة وخادم الويب. خصص لـ Redis جزءاً مما يتبقى، ثم افحص used_memory_human في redis-cli info memory بعد يوم من حركة المرور واضبط القيمة. يستقر موقع WordPress واحد عادةً عند عشرات الميغابايتات، لذلك يكون maxmemory بسعة 256 MB بداية سخية على خادم بسعة 4 GB.

لماذا أصبح موقعي أبطأ بعد تفعيل ذاكرة Redis المؤقتة للكائنات؟

السبب المعتاد هو امتلاء المثيل الذي يستخدم سياسة noeviction. يرفض Redis عمليات الكتابة الجديدة ويعيد OOM command not allowed when used memory > 'maxmemory'.، لذلك يعود WordPress إلى قاعدة البيانات لكل قيمة، ويتحمّل بالإضافة إلى ذلك زمناً ضائعاً في رحلة ذهاب وإياب إلى Redis. افحص redis-cli config get maxmemory-policy، واضبط allkeys-lru، وتأكد من أن maxmemory ليست صغيرة جداً. ومن الأسباب الشائعة الأخرى تشغيل خادم Redis على مضيف بعيد، إذ تتراكم مئات الرحلات ذهاباً وإياباً في كل طلب، ووجود قيمة خيارات محمّلة تلقائياً بحجم عدة ميغابايتات تعبر الاتصال في كل طلب.

هل يمكن لعدة مواقع WordPress مشاركة خادم Redis واحد؟

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

هل من الآمن حذف wp-content/object-cache.php؟

نعم. هذا ملف drop-in وليس جزءاً من نواة WordPress، وإزالته تعيد WordPress إلى ذاكرة التخزين المؤقت المضمنة لديه لكل طلب. سيستمر الموقع في العمل، لكنه سينفذ ببساطة استعلامات أكثر إلى قاعدة البيانات. يُفضّل استخدام wp redis disable، الذي يحذف الملف بطريقة سليمة ويعرض Object cache disabled.. ويكون حذفه يدوياً الإجراء الطارئ المناسب إذا كان Redis متوقفاً أو يعمل بصورة غير صحيحة ولا يمكنك الوصول إلى لوحة الإدارة.