Redis در وردپرس معمولاً برای persistent object cache استفاده می‌شود: نتیجه بعضی محاسبات و داده‌های قابل cache بین درخواست‌ها در حافظه باقی می‌ماند تا query یا پردازش تکراری کمتر شود. این با page cache فرق دارد و HTML کامل صفحه را الزاماً تحویل نمی‌دهد. اگر bottleneck شبکه، تصویر یا یک API کند باشد، Redis ممکن است تقریباً بی‌اثر باشد.
پاسخ کوتاه: Redis زمانی مفید است که درخواست‌های dynamic queryهای تکراری و cacheپذیر داشته باشند و hit rate مناسب ایجاد شود. قبل و بعد، زمان query، TTFB، hit/miss، مصرف RAM و error rate را بسنجید. صرف روشن شدن پیام «Connected» اثبات افزایش سرعت نیست.
Object Cache وردپرس چه کاری می‌کند؟
وردپرس در طول یک request objectهایی را cache می‌کند، اما بدون backend پایدار این داده معمولاً با پایان request از بین می‌رود. drop-in مربوط به object cache می‌تواند آن را به Redis متصل کند تا درخواست بعدی از داده معتبر استفاده کند. افزونه مسئول serialization، گروه‌ها، prefix و invalidation است؛ Redis به تنهایی منطق وردپرس را نمی‌شناسد.
تفاوت Redis با Page Cache
| ویژگی | Object Cache/Redis | Page Cache |
|---|---|---|
| واحد cache | object و نتیجه داده | HTML کامل پاسخ |
| کاربر واردشده | می‌تواند مفید باشد | اغلب bypass می‌شود |
| checkout/API | با invalidation درست قابل استفاده | معمولاً نباید عمومی cache شود |
| کاهش اجرای PHP | خیر، PHP هنوز اجرا می‌شود | در hit ممکن است PHP دور زده شود |
| ریسک اصلی | stale data، collision و memory | نشت پاسخ شخصی و invalidation |
چه سایت‌هایی بیشتر سود می‌برند؟
- کاربران واردشده و صفحات dynamic زیاد
- queryهای تکراری و cacheپذیر
- فروشگاه یا membership که page cache محدودتری دارد
- چند PHP worker که نتیجه مشترک قابل استفاده دارند
- دیتابیس با latency قابل‌اندازه‌گیری در خواندن‌های تکراری
سایت کوچک و عمدتاً static که page cache نرخ hit بالایی دارد ممکن است تفاوت کمی ببیند. ابتدا bottleneck کندی وردپرس را مشخص کنید.
چه زمانی Redis مشکل را حل نمی‌کند؟
تصویر بزرگ، JavaScript سنگین، DNS کند، CPU loop، HTTP call خارجی، query غیرقابل cache یا کمبود PHP worker با نصب Redis خودکار رفع نمی‌شود. اگر cache هر لحظه purge شود یا کلیدها TTL نامناسب داشته باشند، hit rate پایین می‌ماند. Redis جای index و طراحی query درست را نیز نمی‌گیرد.
پیش‌نیازهای نصب حرفه‌ای
- baseline زمان پاسخ و query را ثبت کنید.
- سازگاری افزونه object cache با نسخه وردپرس/PHP را بررسی کنید.
- Redis را روی شبکه خصوصی یا socket امن در دسترس قرار دهید.
- برای هر سایت prefix یا دیتابیس منطقی مناسب تعریف کنید.
- سقف memory و eviction policy را بر اساس نوع داده تعیین کنید.
- مانیتورینگ connection، hit rate، eviction و memory بسازید.
- روش disable و rollback drop-in را تمرین کنید.
قرار دادن Redis بدون authentication یا شبکه خصوصی روی اینترنت خطرناک است. پورت آن نباید صرفاً برای اتصال آسان عمومی شود.
افزونه و Drop-in را چگونه انتخاب کنیم؟
از راهکاری استفاده کنید که نسخه‌های وردپرس، PHP و topology Redis شما را رسماً پشتیبانی کند، نگهداری فعال و مسیر disable روشن داشته باشد. وجود چند افزونه cache که هم‌زمان فایل object-cache.php را مدیریت می‌کنند، مالکیت مبهم و رفتار غیرقابل پیش‌بینی می‌سازد. پیش از تعویض افزونه، drop-in فعلی و تنظیم prefix را inventory کنید.
فایل اتصال، رمز و host نباید وارد repository عمومی یا screenshot شود. secret را متناسب با محیط مدیریت کنید و دسترسی user Redis را تا حد قابلیت نسخه مورد استفاده محدود نگه دارید. production و staging باید config و namespace جدا داشته باشند.
برنامه Rollback Redis
- روش رسمی غیرفعال‌سازی object cache را ثبت کنید.
- تأیید کنید سایت بدون Redis می‌تواند با load قابل‌کنترل به MySQL برگردد.
- drop-in باقی‌مانده و تنظیمات اتصال را پس از disable بررسی کنید.
- در staging، قطع کوتاه Redis و timeout را شبیه‌سازی کنید.
- پس از rollback، error rate، PHP queue و بار دیتابیس را مانیتور کنید.
حذف تصادفی فایل یا stop کردن Redis زیر ترافیک ممکن است موج درخواست به دیتابیس بسازد. rollback را در پنجره کنترل‌شده و با ظرفیت کافی انجام دهید.
Memory و Eviction
Redis عمداً RAM مصرف می‌کند. باید سقف آن در کنار PHP-FPM، MySQL و سیستم محاسبه شود؛ راهنمای مصرف RAM وردپرس این سهم‌ها را تفکیک می‌کند. اگر eviction زیاد است، یا ظرفیت کم است یا داده و TTL مناسب نیست. افزایش RAM بدون بررسی کلیدهای بزرگ می‌تواند رشد را فقط عقب بیندازد.
Cache stampede و cold start
پس از flush، درخواست‌های زیادی ممکن است هم‌زمان داده را از دیتابیس بازسازی کنند و load بالا رود. پاک‌سازی دوره‌ای کل Redis راه نگهداری سالم نیست. invalidation باید هدفمند باشد و warm-up یا lock برای داده گران با پشتیبانی لایه برنامه طراحی شود.
چند سایت روی یک Redis
prefix یکتا برای جلوگیری از برخورد کلید ضروری است. با این حال جداسازی منطقی همیشه جداسازی منابع و امنیت کامل نیست؛ eviction یک workload می‌تواند سایت دیگر را تحت تأثیر بگذارد. برای محیط‌های حساس، instance یا policy جدا را بررسی کنید. staging نباید cache production را مصرف یا flush کند.
چگونه نتیجه را اندازه بگیریم؟
- چند URL dynamic و سناریوی login را انتخاب کنید.
- cache سرد و گرم را برچسب بزنید.
- TTFB، زمان PHP و query را قبل و بعد مقایسه کنید.
- hit/miss، eviction و memory Redis را ثبت کنید.
- CPU و latency MySQL را کنترل کنید.
- صحت داده و invalidation را با دو نشست آزمایش کنید.
میانگین به تنهایی کافی نیست؛ صدک‌های کندتر و error rate را ببینید. بهبود cache hit نباید با نمایش موجودی یا مجوز قدیمی به دست آمده باشد.
اشتباه‌های رایج
- فرض اینکه Redis همان page cache است
- flush زمان‌بندی‌شده به‌جای اصلاح invalidation
- اشتراک prefix میان production و staging
- باز کردن پورت Redis روی اینترنت
- نداشتن سقف memory و alert eviction
- اعلام موفقیت فقط از روی وضعیت Connected
اگر Redis قطع شود چه می‌شود؟
رفتار به افزونه و معماری بستگی دارد. ideally سایت باید با fallback کنترل‌شده به دیتابیس ادامه دهد، اما load ناگهانی می‌تواند MySQL را اشباع کند. failure mode را در staging آزمایش، timeout اتصال را معقول و runbook غیرفعال‌سازی drop-in را مستند کنید.
چه زمانی بررسی تخصصی لازم است؟
اگر صفحات dynamic کندند، MySQL زیر بار بالا می‌رود یا چند سایت از Redis مشترک استفاده می‌کنند، تنظیم حدسی خطر stale data و OOM دارد. سرویس افزایش سرعت وردپرس می‌تواند سود واقعی Redis را با workload و metricهای قبل و بعد بررسی کند.
پرسش‌های متداول
آیا Redis برای هر سایت وردپرسی لازم است؟
خیر؛ سود آن به workload dynamic و queryهای cacheپذیر وابسته است.
آیا با Redis دیتابیس حذف می‌شود؟
خیر. Redis cache است و منبع اصلی داده معمولاً MySQL باقی می‌ماند.
آیا پاک کردن Redis امن است؟
ممکن است داده cache بازسازی شود، اما load ناگهانی و اختلال افزونه محتمل است؛ بدون شناخت namespace و اثر، flush نکنید.