
به اشتراک بگذارید

به اشتراک بگذارید
صفحه تنظیمات افزونه سبز شده و جلوی Status نوشته Connected. در نردبان redis object cache ووکامرس این تازه سطح صفر است. سه سطح دیگر مانده و هر کدام یک تمرین و یک نمره قبولی دارد.
wp redis status اتصال و پیشوند Redis شما را نشان میدهد.CONFIG GET maxmemory دیگر صفر برنمیگرداند.💡 کاری که این کش برای وردپرس میکند
کش آبجکت پایدار داده خواندهشده از دیتابیس را بین درخواستها در Redis نگه میدارد. بدون آن، وردپرس این داده را آخر هر درخواست دور میریزد.
✅ وضعیت Connected فقط اتصال را تأیید میکند و سرعت را باید جدا سنجید.
✅ تمرین ریاستارت را دور از فروشگاه اصلی انجام دهید.
هر سطح یک بررسی دارد. اولین بررسی ردشده، سطح فروشگاه را نشان میدهد. کش آبجکت فقط یک مهره از بهینه سازی ووکامرس روی سرور است و PHP-FPM و دیتابیس مهرههای دیگرش.
📌 سطحبندی کش آبجکت فروشگاه
◀️ سطح صفر: اتصال بدون اندازهگیری
◀️ حافظه و سیاست حذف
◀️ سنجش hit و miss روی سبد خرید
◀️ ریاستارت Redis و فروشگاه

سطح صفر از ۳. redis object cache ووکامرس دادهای را که وردپرس با کوئری از دیتابیس خوانده، برای درخواست بعدی در حافظه میگذارد. صفحه HTML آماده آنجا نمیماند. افزونه Redis Object Cache این حافظه را با یک فایل drop-in به Redis میبرد.
سبد، صفحه پرداخت و حساب کاربری به خواست راهنمای پیکربندی افزونههای کش ووکامرس از کش صفحه بیرون میمانند. کش آبجکت روی این صفحههای مخصوص هر مشتری هنوز کار میکند. نشانی صفحه برایش مهم نیست. کمبود پردازه PHP-FPM را اما جبران نمیکند.
مطلب Redis چیست فرمانهای پایه redis-cli را یاد میدهد؛ سطح ۱ و ۲ با همانها سنجیده میشوند. روی Ubuntu 24.04 سرور Redis و افزونه PHP به نام php-redis را نصب کنید. بعد PHP-FPM را ریاستارت کنید. بدون php-redis، افزونه سراغ Predis داخلی خودش میرود.
sudo apt update
sudo apt install redis-server php-redis
sudo systemctl restart php8.3-fpm
نام سرویس را با نسخه PHP سایت خودتان بنویسید. پیش از روشن کردن کش، ثابتها را در wp-config.php بگذارید؛ وگرنه افزونه اول با دیتابیس 0 و بیپیشوند وصل میشود.
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 2 );
define( 'WP_REDIS_PREFIX', 'shop1_' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
🔸 ثابتهایی که بالای wp-settings.php مینشینند
۱) مقدار WP_REDIS_PREFIX برای هر سایت یکتا باشد تا کلیدها قاطی نشوند.
۲) مقدار WP_REDIS_DATABASE بین 0 تا 15 است و هر سایت عدد خودش را میگیرد.
۳) جای همه بالای خط «stop editing» است.
بعد افزونه را از صفحه Redis Object Cache در مخزن وردپرس یا با WP-CLI نصب و روشن کنید. فرمانها را در پوشه وردپرس و با کاربر صاحب فایلها بزنید.
wp plugin install redis-cache --activate
wp redis enable
wp redis status
نمره قبولی: خروجی wp redis status اینها را دارد: Status برابر Connected، Drop-in برابر Valid و دو خط WP_REDIS_PREFIX و WP_REDIS_DATABASE با همان مقدارهای wp-config.php. خط Global Prefix پیشوند جدولهای وردپرس است، مثلاً wp_.
سطح ۱ از ۳. روی سیستم ۶۴ بیتی، Redis بهطور پیشفرض سقف حافظه ندارد و maxmemory صفر است. بدون سقف، وردپرس مدام کلید تازه به redis object cache ووکامرس میفرستد. چیزی جلوی رشد حافظه را نمیگیرد.
روی Ubuntu فایل تنظیم در مسیر /etc/redis/redis.conf است. این دو خط را اضافه یا ویرایش کنید:
maxmemory 256mb
maxmemory-policy allkeys-lru
عدد 256mb نمونه است و روش سنجیدنش در پرسشهای پایانی است. فرمان CONFIG SET همین مقدارها را بیریاستارت اعمال میکند. فایل برای ریاستارت بعدی است.
redis-cli CONFIG SET maxmemory 256mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
redis-cli CONFIG GET maxmemory-policy
در فایل پیشفرض redis.conf سیاست روی noeviction است. تا maxmemory صفر است خطایی نمیبینید. سقف که گذاشتید و سیاست ماند، Redis پرشده گارسونی است که سفارش ثابتها را از بر دارد و چیزی از یاد نمیبرد: سفارش تازه را رد میکند. وردپرس این رد شدن را با خطای OOM command not allowed گزارش میکند.
💡 دو سیاست و دو رفتار هنگام پر شدن
با noeviction هیچ کلیدی حذف نمیشود. فرمانی که داده تازه مینویسد خطا میگیرد. با allkeys-lru، Redis کلیدی را حذف میکند که مدتها کسی سراغش نرفته. مستندات سیاستهای حذف Redis همین را پیشفرض مناسب کش میداند.
پرسشهای متداول افزونه برای هر دامنه یک WP_REDIS_DATABASE و یک WP_REDIS_PREFIX جدا میخواهد. وگرنه ممکن است سایتی به دامنه دیگر ریدایرکت شود. این فرمان برای هر دیتابیس دارای کلید یک خط db نشان میدهد:
redis-cli INFO keyspace
فایل پیشفرض Redis با bind 127.0.0.1 -::1 فقط روی loopback گوش میدهد. protected-mode yes هم در آن روشن است. پورت 6379 را به اینترنت باز نکنید.
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode
نمره قبولی: سقف maxmemory غیرصفر. سیاست allkeys-lru. bind فقط روی loopback. هر سایت با دیتابیس و پیشوند خودش.

سطح ۲ از ۳. صفحه سبد خرید محک واقعی redis object cache ووکامرس است. کش صفحه آنجا کنار رفته و هر درخواست به PHP و دیتابیس میرسد. دو عدد لازم است: تعداد کوئری صفحه و نسبت hit خود Redis.
افزونه Query Monitor را نصب کنید و با حساب مدیر محصولی به سبد بیندازید. در منوی آن روی نوار مدیریت، عدد اول زمان تولید صفحه است. عدد آخر، با حرف Q، تعداد کوئریهاست. افزونه Redis پنل Object Cache را با Hit Ratio همان درخواست اضافه میکند.
تمرین: با wp redis disable کش را خاموش کنید. سبد را چند بار بارگذاری کنید و عددها را بنویسید. بعد wp redis enable بزنید. بارگذاری اول کش را پر میکند. از دومی به بعد بخوانید.
| معیار | کجا در Query Monitor | عدد شما: کش خاموش | عدد شما: کش روشن |
|---|---|---|---|
| تعداد کوئری SQL | عدد آخر منو، با حرف Q | …… | …… |
| زمان تولید صفحه | عدد اول منو | …… | …… |
| نسبت Hit | پنل Object Cache | ندارد | …… |
عدد هر فروشگاه فرق دارد. اگر نسبت Hit بین بارگذاریها بالا نرفت، شاید افزونهای کش را مدام پاک میکند. برای ردگیری آن، سازنده افزونه اکشن redis_object_cache_flush را معرفی کرده است.
افزونه Query Monitor فقط یک درخواست را میبیند. برای یک روز کامل، شمارندههای Redis را صفر کنید و فردا بخوانید. این کار آمار INFO کل سرور را صفر میکند.
redis-cli CONFIG RESETSTAT
redis-cli INFO stats | grep -E 'keyspace_(hits|misses)|evicted_keys'
فرمول مستندات Redis: keyspace_hits تقسیم بر جمع hits و misses، ضرب در صد. اگر evicted_keys بالاست و نسبت پایین، سیاست حذف کلیدهای لازم را زیادی بیرون میاندازد. با چند سایت روی یک Redis، عدد مال همه است.
نمره قبولی: کوئری سبد با کش روشن کمتر شده است. نسبت hit یک شبانهروز هم یادداشت شده.

سطح ۳ از ۳. تا Redis دوباره بالا نیامده، پیکربندی پیشفرض redis object cache ووکامرس بهجای فروشگاه پیام Error establishing a Redis connection نشان میدهد.
در فایل object-cache.php نسخه 3.0.0، خطای اتصال فقط وقتی بیصدا ثبت میشود که ثابت WP_REDIS_GRACEFUL تعریف و true شده باشد. وگرنه wp_die صفحه خطا برمیگرداند. README در مخزن GitHub افزونه این ثابت را پشتیبانینشده میداند و هشدار میدهد داده را خراب میکند. فایل wp-content/redis-error.php را بسازید تا افزونه آن را بهجای صفحه پیشفرض نشان دهد.
ریاستارت Redis همه سایتهای وصل به آن را با هم از کار میاندازد. اگر کپی آزمایشی روی همان سرور و همان Redis است، فروشگاه اصلی هم صفحه خطا میدهد. تمرین را روی سرور آزمایشی جدا یا در پنجره نگهداری انجام دهید. حلقه curl را در یک ترمینال روشن کنید و در دیگری ریاستارت بزنید؛ تعداد سطرهای غیر از 200 مدت قطعی به ثانیه است.
while true; do curl -s -o /dev/null -w '%{http_code}\n' https://staging.example.com/cart/; sleep 1; done
sudo systemctl restart redis-server
برگشتن کلیدها بعد از ریاستارت به تنظیم ماندگاری (persistence) سرور بستگی دارد. اگر برنگشتند، کش از دیتابیس دوباره پر میشود. نسبت hit کمکم بالا میرود.
سرویس Redis بالا نمیآید و فروشگاه خوابیده؟ این خط را بالای «stop editing» در wp-config.php بگذارید؛ README میگوید کش را دور میزند و drop-in را پاک نمیکند. راه دیگر حذف wp-content/object-cache.php است.
define( 'WP_REDIS_DISABLED', true );
برای خالی کردن کش یک سایت با دیتابیس جدا، wp cache flush را از پوشه همان سایت اجرا کنید. فرمان redis-cli FLUSHALL همه دیتابیسهای Redis را خالی میکند، یعنی کش همه سایتها را.
نمره قبولی: مدت قطعی را با حلقه curl اندازه گرفتهاید. جای WP_REDIS_DISABLED را بلدید.
نمودار حافظه Redis در مانیتورینگ هر روز کمی بالاتر میایستد. سرور هنوز خطایی نداده، اما هر صبح اول از همه همین نمودار را باز میکنید.
بعد از یک روز ترافیک دو عدد را ببینید: used_memory_peak_human از INFO memory و evicted_keys از INFO stats. اوج نزدیک سقف و evicted_keys رو به بالا یعنی سقف تنگ است.
اگر کش صفحه آن را نگه داشته، تفاوت کمی حس میشود. بیشترین اثر روی صفحههایی است که کش صفحه کنار میگذارد، مثل سبد خرید.
خیر. کش آبجکت بر پایه نشانی صفحه کار نمیکند. فقط گروههای کش را میتوان با WP_REDIS_IGNORED_GROUPS از Redis بیرون نگه داشت.
حافظه Redis به سقف رسیده و سیاست هنوز noeviction است. سیاست را allkeys-lru کنید. راه دیگر در پرسشهای متداول افزونه: WP_REDIS_MAXTTL را مثلاً 3600 ثانیه بگذارید و کش را یک بار خالی کنید.
بله، با WP_REDIS_DATABASE و WP_REDIS_PREFIX جدا برای هر کدام.
ترنزینتهای تازه به Redis میروند و ردیفهای قبلی در جدول options میمانند. سازنده افزونه پاک کردنشان را پیشنهاد میکند.
روی loopback فقط همان سرور وصل میشود. اما هر کاربر و پردازه محلی هم میتواند کش را بخواند و پاک کند. روی سرور چندکاربره یا Redis جدا، رمز یا ACL بگذارید و با WP_REDIS_PASSWORD به افزونه بدهید.
جمعبندی؛ سطحی که فروشگاه امروز در آن ایستاده. یک redis object cache ووکامرس کامل هر سه سطح بالای صفر را گذرانده است. پیشوند و دیتابیس جدا دارد و خط WP_REDIS_PREFIX آن را تأیید میکند. سقف حافظه دارد و سیاستش allkeys-lru است. Redis فقط به خود سرور جواب میدهد. عدد کوئری صفحه سبد خرید را قبل و بعد نوشتهاید. نسبت hit یک شبانهروز را هم دارید. مدت قطعی ریاستارت را اندازه گرفتهاید. WP_REDIS_DISABLED هم برای روز مبادا آماده است. صفحههای پویای ووکامرس هنوز به پردازه کافی PHP و دیتابیس تنظیمشده هم تکیه دارند.
🚀 سقف بعدی فروشگاه، پشت Redis
بخشی از کوئریهای سبد خرید حالا از حافظه جواب میگیرند. از اینجا به بعد، سرعت را تعداد پردازههای PHP-FPM و اندازه بافر InnoDB تعیین میکند.
نسبت hit سرورتان بعد از یک شبانهروز کامل ترافیک چند درصد شد؟
منابع