Page Cache پاسخ HTML آماده را نگه می‌دارد تا در cache hit اجرای کامل وردپرس دور زده شود. Object Cache داده‌ها و نتیجه بعضی محاسبات را نگه می‌دارد، اما PHP همچنان درخواست را اجرا می‌کند. این دو رقیب هم نیستند و فعال بودن یکی به معنی بی‌نیازی قطعی از دیگری نیست؛ انتخاب به نوع ترافیک و صفحات dynamic بستگی دارد.
پاسخ کوتاه: برای صفحات عمومی یکسان، Page Cache معمولاً اثر مستقیم‌تری بر TTFB و بار PHP دارد. برای wp-admin، کاربران واردشده، API و بخش‌هایی که HTML عمومی قابل cache نیست، Object Cache ممکن است queryهای تکراری را کم کند. صحت invalidation و جداسازی داده از خود سرعت مهم‌تر است.
مقایسه مستقیم دو نوع Cache
| ویژگی | Page Cache | Object Cache |
|---|---|---|
| چه چیزی ذخیره می‌شود؟ | پاسخ کامل HTML | object، option و نتیجه داده |
| اجرای PHP در hit | ممکن است دور زده شود | ادامه دارد |
| کاربر ناشناس | بسیار مناسب برای صفحه عمومی | بسته به query مفید |
| کاربر واردشده | اغلب bypass | می‌تواند مفید باشد |
| سبد و checkout | نباید به‌صورت عمومی cache شود | با سازگاری و invalidation درست |
| ریسک اصلی | نمایش پاسخ شخصی به کاربر دیگر | داده stale، collision و مصرف RAM |
Page Cache در عمل چگونه کار می‌کند؟
کلید cache معمولاً از host، path، query و گاهی cookie یا زبان ساخته می‌شود. در hit، CDN، reverse proxy یا افزونه می‌تواند HTML قبلی را برگرداند. اگر variation لازم در کلید نباشد، قیمت، زبان یا محتوای شخصی اشتباه نمایش داده می‌شود. اگر variation بیش‌ازحد باشد، hit rate افت می‌کند.
روش cache در CDN، Nginx و افزونه وردپرس یکسان نیست. چند لایه cache بدون شناخت purge می‌توانند نسخه قدیمی را نگه دارند. headerهای cache، age و مسیر purge را مستند کنید.
Object Cache در یک Request و بین Requestها
وردپرس object cache داخلی دارد، اما بدون backend پایدار داده معمولاً با پایان request از بین می‌رود. drop-inهایی مثل اتصال Redis آن را persistent می‌کنند. افزونه اتصال مسئول prefix، serialization، گروه‌ها و رفتار failure است؛ Redis منطق permission یا موجودی ووکامرس را خودکار نمی‌فهمد.
جزئیات نصب و ارزیابی در راهنمای Redis برای وردپرس آمده است. وضعیت Connected فقط اتصال را ثابت می‌کند، نه hit rate یا افزایش سرعت.
برای هر نوع صفحه کدام مناسب‌تر است؟
- مقاله عمومی: Page Cache معمولاً اولویت دارد.
- wp-admin: Page Cache عمومی مناسب نیست؛ Object Cache شاید کمک کند.
- جستجو و فیلتر: به تنوع query و سیاست cache وابسته است.
- حساب کاربری: HTML شخصی؛ Object Cache سازگار محتمل‌تر است.
- checkout: صحت session، قیمت و موجودی مقدم است.
- REST API: public read با private write یک policy ندارد.
Cache Hit، Miss و Bypass
Hit یعنی پاسخ یا object پیدا شده، miss یعنی باید ساخته شود و bypass یعنی policy اجازه استفاده نمی‌دهد. هر سه را در اندازه‌گیری جدا کنید. درخواست اول پس از purge با درخواست گرم برابر نیست. نرخ hit بالا نیز اگر داده اشتباه تحویل دهد موفقیت نیست.
Invalidation سخت‌ترین بخش Cache است
بعد از ویرایش نوشته، تغییر قیمت، سفارش یا تغییر نقش، داده مرتبط باید منقضی شود. purge کل cache ساده به نظر می‌رسد ولی cold start و فشار ناگهانی به PHP/MySQL می‌سازد. invalidation هدفمند، TTL متناسب و تست چند نشست لازم است.
در ووکامرس، ارزیابی Redis برای فروشگاه باید قیمت، موجودی، coupon، مالیات و callback پرداخت را پوشش دهد.
سه لایه Cache رایج
- Browser/CDN: asset و گاهی HTML عمومی نزدیک کاربر.
- Page Cache در origin: پاسخ کامل بدون اجرای سنگین application.
- Object Cache: کاهش query و محاسبه در requestهای PHP.
OPcache لایه دیگری است که bytecode PHP را cache می‌کند و با Object Cache داده برابر نیست. استفاده از واژه «cache» برای همه این لایه‌ها نباید باعث یکی دانستن تنظیم و purge آن‌ها شود.
چگونه انتخاب کنیم؟
- صفحات و کاربران اصلی را دسته‌بندی کنید.
- TTFB، PHP time و query time baseline بگیرید.
- سهم hit و dynamic traffic را مشخص کنید.
- یک لایه را با policy روشن فعال کنید.
- hit/miss، منابع و صحت محتوا را بسنجید.
- failure و rollback را در staging آزمایش کنید.
اگر صفحه عمومی در hit سریع است ولی wp-admin کند است، افزودن Page Cache دیگر کمکی نمی‌کند. برای تشخیص پایه، راهنمای کندی وردپرس را دنبال کنید.
امنیت و جداسازی
Redis نباید بدون کنترل شبکه روی اینترنت باز باشد. production و staging باید prefix و تنظیم جدا داشته باشند. در Page Cache نیز cookie و authorization باید درست bypass شوند. با دو کاربر و دو مرورگر آزمایش کنید که داده شخصی جابه‌جا نمی‌شود.
برای هر لایه چه چیزی را مانیتور کنیم؟
در Page Cache، hit rate، bypass reason، age، purge و زمان origin را ثبت کنید. در Object Cache، hit/miss، eviction، memory، latency و خطای اتصال مهم‌اند. این metricها را با TTFB، PHP queue و بار MySQL در یک بازه زمانی مقایسه کنید؛ نمودار جداگانه بدون timeline مشترک علت را روشن نمی‌کند.
هشدار باید قابل اقدام باشد. مثلاً افزایش eviction همراه با رشد query و latency ارزش بیشتری از هشدار صرف «RAM Redis بالا» دارد، چون Redis برای استفاده از RAM طراحی شده است. برای Page Cache نیز افت hit rate بعد از deployment باید با تغییر rule یا purge قابل پیگیری باشد.
برنامه خرابی و Rollback
پیشاپیش بدانید در قطع Redis، خرابی افزونه cache یا purge اشتباه چه کسی و چگونه لایه را bypass می‌کند. حذف ناگهانی drop-in یا restart زیر بار می‌تواند موج درخواست به origin بسازد. rollback را در staging آزمایش و بعد از آن error rate، صف PHP و MySQL را مانیتور کنید.
اشتباه‌های رایج
- فعال کردن چند افزونه Page Cache هم‌زمان
- فرض اینکه Redis HTML را کامل cache می‌کند
- cache عمومی checkout یا حساب کاربری
- flush زمان‌بندی‌شده برای پنهان کردن invalidation خراب
- اشتراک namespace بین staging و production
- ارزیابی فقط با یک درخواست گرم
چه زمانی کمک تخصصی لازم است؟
اگر چند لایه CDN، proxy و Redis دارید یا صفحات شخصی و تراکنشی مهم‌اند، یک rule اشتباه می‌تواند داده نادرست نمایش دهد. سرویس افزایش سرعت وردپرس می‌تواند معماری cache را بر اساس hit rate، صحت و workload واقعی ارزیابی کند.
پرسش‌های متداول
آیا به هر دو Cache نیاز داریم؟
نه همیشه؛ برای سایت ترکیبی ممکن است مکمل باشند، اما نیاز باید با نوع ترافیک و اندازه‌گیری ثابت شود.
آیا Object Cache دیتابیس را حذف می‌کند؟
خیر. دیتابیس منبع اصلی است و cache فقط بخشی از خواندن و محاسبه را کم می‌کند.
چرا بعد از purge سایت کند می‌شود؟
cache سرد است و درخواست‌ها داده را بازسازی می‌کنند؛ purge گسترده می‌تواند stampede ایجاد کند.