آموزش راه‌اندازی Object Cache در وردپرس با Redis و Memcached

آموزش راه‌اندازی Object Cache در وردپرس با Redis و Memcached

Object Cache در وردپرس مکانیزمی است که نتیجهٔ کوئری‌های پایگاه داده و محاسبات تکراری را در حافظه نگه می‌دارد تا هر بازدید صفحه، همهٔ پرس‌وجوها را از صفر اجرا نکند. اگر سایت شما روی سروری با منابع محدود اجرا می‌شود و تعداد کوئری هر صفحه بالاست، این لایه معمولاً بیشترین بازدهی را نسبت به هزینهٔ راه‌اندازی و نگهداری دارد. نکتهٔ کلیدی اینجاست که هستهٔ وردپرس از ابتدا یک کش شیء دارد، اما این کش غیرپایدار است؛ یعنی داده فقط در طول یک درخواست زنده می‌ماند و با پایان رندر صفحه از حافظه پاک می‌شود.

به همین دلیل وقتی توسعه‌دهندگان از «فعال‌سازی Object Cache» حرف می‌زنند، منظورشان تقریباً همیشه یک کش پایدار با Redis یا Memcached است که بین درخواست‌ها و بین کاربران مختلف مشترک باقی می‌ماند. تفاوت این دو حالت در عمل بسیار بزرگ است: در حالت غیرپایدار، هر بازدیدکننده یک چرخهٔ کامل کوئری را تحمل می‌کند؛ در حالت پایدار، پاسخ‌های سنگین از حافظهٔ رم سرو می‌شوند.

این مقاله روی بخش عملی متمرکز است: چه زمانی کش شیء به کار می‌آید، Redis یا Memcached کدام را انتخاب کنیم، چگونه آن را بدون شلوغ‌کاری به وردپرس وصل کنیم، نتیجه را چطور اندازه بگیریم و از کجا ممکن است سایت را بشکنیم. پیش از شروع توصیه می‌کنم با مدیریت حافظه در وردپرس هم آشنا باشید، چون محدودیت PHP Memory Limit و کش شیء دو موضوع جدا هستند که در عمل روی هم اثر می‌گذارند.

Object Cache در وردپرس دقیقاً کجا دخالت می‌کند؟

هر بار که یک صفحهٔ وردپرسی رندر می‌شود، مجموعه‌ای از پرس‌وجوها اجرا می‌شود: بارگذاری تنظیمات از جدول wp_options، خواندن پست‌ها و متادیتا، بررسی نقش کاربر، محاسبهٔ منوها و در سایت‌های فروشگاهی خواندن محصولات و موجودی. بسیاری از این داده‌ها بین درخواست‌ها تغییر نمی‌کنند، ولی وردپرس در حالت پیش‌فرض مجبور است هر بار آن‌ها را از MySQL بخواند.

کش شیء دقیقاً همین‌جا وارد می‌شود. تابع‌های کش وردپرس یک فضای نام‌گذاری‌شده با دو بخش دارند: یک کلید و یک گروه. کلید، شناسهٔ یکتا برای آن داده است و گروه، دسته‌ای منطقی که کنار هم نگه‌داری و پاک می‌شوند. وقتی یک لایهٔ پایدار مثل Redis پشت این ساختار قرار بگیرد، داده در حافظهٔ رم ذخیره می‌شود و درخواست بعدی بدون رفتن به دیتابیس، همان مقدار را برمی‌دارد.

مزیت پنهان این ساختار، هزینهٔ پایین کوئری‌های سبک است. برخی کوئری‌ها به‌تنهایی خطرناک نیستند، اما وقتی در هر صفحه ده‌ها بار تکرار می‌شوند، زمان کسرشده از پاسخ سرور جمع می‌شود. کش شیء همان ذخیره‌سازی مکرر را حذف می‌کند.

تفاوت Object Cache با Page Cache، Opcode Cache و Transient

هر لایهٔ کش در وردپرس مسئول بخش متفاوتی از زنجیرهٔ رندر است و اشتباه گرفتنشان باعث تنظیم غلط و انتظار بی‌جا می‌شود.

• Page Cache خروجی نهایی HTML یک صفحه را برای کاربران مهمان ذخیره می‌کند و درخواست را پیش از رسیدن به وردپرس پاسخ می‌دهد.
• Object Cache دادهٔ سطح پایین‌تر را در حافظه نگه می‌دارد؛ یعنی نتیجهٔ توابع و کوئری‌ها، نه HTML نهایی. به همین دلیل روی صفحات پویا، پنل مدیریت و کاربران واردشده هم اثر می‌گذارد.
• Opcode Cache در سطح PHP کار می‌کند و بایت‌کد فایل‌های PHP را ذخیره می‌کند تا پارس مجدد لازم نباشد. امروزه این لایه معمولاً با OPcache فعال است.
• Transient یک API سطح بالا در وردپرس است که برای داده‌های موقت طراحی شده و پیاده‌سازی آن به کش شیء وابسته است؛ اگر کش پایدار وجود نداشته باشد، Transientها در جدول wp_options ذخیره می‌شوند.

همین وابستگی نشان می‌دهد که فعال‌سازی کش پایدار، کیفیت رفتار Transientها در افزونه‌ها را هم تغییر می‌دهد. در سایت‌هایی که افزونه‌های زیادی روی جدول wp_options کار می‌کنند، این تغییر می‌تواند محسوس باشد. اگر می‌خواهید تصویر کامل‌تری از گلوگاه‌های سرعت داشته باشید، مقالهٔ حل مشکل لود نشدن و کم بودن سرعت لود سایت‌های وردپرسی مسیر عیب‌یابی را گام‌به‌گام نشان می‌دهد.

پیشنهادات

افزونه قدرتمند بازاریابی و پورسانت دهی وردپرس و ووکامرس Affiliate Program

wp-wc-affiliate program یک افزونه قدرتمند و بسیار...

دانلود رایگان افزونه قدرتمند Jet Engine برای المنتور

  افزونه قدرتمند Jet Engine برای المنتور...

جلوگیری از سئوی بیش از حد در وردپرس با کنترل کلمات کلیدی

جلوگیری از سئوی بیش از حد -...

سایت آماده گل و گیاه آپارتمانی – سایت آماده فلورینا

سایت آماده گل و گیاه آپارتمانی -...

استفاده از هوش مصنوعی در وردپرس – چرا و چگونه؟

استفاده از هوش مصنوعی در وردپرس یکی...

کلاس WP_Object_Cache و توابع wp_cache_*

در هستهٔ وردپرس، کلاس WP_Object_Cache نگه‌دارندهٔ کش درون‌درخواستی است. توسعه‌دهنده مستقیماً با این کلاس کار نمی‌کند؛ بلکه از توابع پوششی استفاده می‌کند که API پایدار محسوب می‌شوند:

• wp_cache_get() برای خواندن مقدار از یک گروه
• wp_cache_set() برای نوشتن مقدار با زمان انقضای مشخص
• wp_cache_delete() برای حذف یک کلید
• wp_cache_flush() برای پاک‌کردن کل کش
• wp_cache_add() برای نوشتن فقط در صورتی که کلید از قبل وجود نداشته باشد

نکتهٔ مهم این است که wp_cache_add() در محیط‌های همزمانی مثل چند وردپرس روی یک سرور، جایگزین قفل واقعی نیست؛ فقط یک بررسی ساده روی وجود کلید انجام می‌دهد.

پیش‌نیازهای راه‌اندازی کش پایدار در وردپرس

پیش از نصب هر چیزی، باید سه چیز را روشن کنید: کدام بک‌اند را می‌خواهید، سرور چه ظرفیتی دارد و مسیر بازگشت شما در صورت خرابی چیست.

Redis یا Memcached؟

هر دو گزینه یک کار انجام می‌دهند: نگه‌داشتن داده در رم و پاسخ‌دادن سریع. تفاوت‌های عملی آن‌ها را می‌توان در چند محور خلاصه کرد.

• Memcached ساده‌تر است، مصرف حافظهٔ سرانهٔ کمتری دارد و برای مقادیر کوچک و پرتعداد طراحی شده است. ساختار داده‌های متنوع ندارد.
• Redis ساختارهای دادهٔ بیشتری پشتیبانی می‌کند، امکان ذخیره‌سازی روی دیسک و بازگردانی دارد و ابزارهای پایش غنی‌تری ارائه می‌دهد.
• در وردپرس، هر دو افزونهٔ جداگانه دارند و برای هر سایت باید فایل object-cache.php در مسیر wp-content قرار بگیرد.

انتخاب، بیشتر به زیرساخت شما بستگی دارد. اگر هاست شما Redis را با یک کلیک ارائه می‌دهد، همان را انتخاب کنید؛ اگر باید خودتان سرویس را نصب و نگهداری کنید، Memcached حجم عملیاتی کمتری دارد. نکتهٔ مهم این است که داده‌های کش، دادهٔ موقت هستند؛ هیچ‌کدام از این دو جایگزین دیتابیس نیستند و از دست رفتنشان نباید هیچ خرابی دائمی ایجاد کند.

بررسی منابع سرور و ظرفیت حافظه

کش در رم زندگی می‌کند، پس باید ظرفیت آزاد واقعی را بدانید. در سرورهای کوچک، اختصاص بیش از اندازهٔ حافظه به Redis می‌تواند فرایندهای PHP-FPM یا MySQL را تحت فشار بگذارد. سقف مصرف را صریح تعیین کنید تا سرویس کش، حافظهٔ سرور را تدریجاً اشغال نکند. در اینجا نمونهٔ یک تنظیم محدودکننده در فایل پیکربندی Redis آمده است؛ مقدار عدد را با احتیاط و متناسب با ظرفیت واقعی سرور تنظیم کنید.

# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru
bind 127.0.0.1
protected-mode yes

خط bind 127.0.0.1 به این معناست که Redis فقط روی حلقهٔ محلی گوش می‌دهد و از بیرون قابل دسترسی نیست. این تنظیم برای اکثر سایت‌های تک‌سروری کافی است و از باز شدن یک پورت حافظه‌ای روی اینترنت جلوگیری می‌کند.

نصب و راه‌اندازی سریع Redis روی سرور

در توزیع‌های مبتنی بر Debian و Ubuntu، نصب Redis چند دستور ساده است. پس از نصب، سالم بودن سرویس را با پینگ بررسی کنید؛ پاسخ PONG یعنی سرویس بالا آمده است. اگر خروجی خطا داد، پیش از ادامه لاگ سرویس را بررسی کنید.

sudo apt update
sudo apt install redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxmemory

بستهٔ php-redis افزونهٔ PHP مورد نیاز را نصب می‌کند. پس از نصب، وب‌سرور را یک بار ری‌استارت کنید تا ماژول بارگذاری شود. اگر از چند نسخهٔ PHP استفاده می‌کنید، مطمئن شوید بسته برای همان نسخه‌ای نصب شده که سایت شما اجرا می‌شود؛ در غیر این صورت افزونهٔ کش پیام «کلاس Redis پیدا نشد» می‌دهد.

در محیط استیجینگ، همیشه از یک نسخهٔ آزمایشی و یک دیتابیس جداگانه استفاده کنید یا حداقل پیشوند کلیدها را از سایت اصلی جدا نگه دارید. اگر سرویس را به‌صورت آزمایشی بالا آورده‌اید، راه بازگشت ساده است: غیرفعال کردن افزونه و حذف فایل object-cache.php از مسیر wp-content.

اتصال وردپرس به Redis

محبوب‌ترین مسیر، نصب افزونهٔ کش شیء مبتنی بر Redis از مخزن رسمی وردپرس و انجام مراحل فعال‌سازی است. افزونه در گام اول یک فایل object-cache.php به‌عنوان drop-in در مسیر wp-content قرار می‌دهد؛ همین فایل است که API کش وردپرس را به Redis متصل می‌کند. در گام بعد، اتصال با استفاده از ثابت‌های wp-config.php تنظیم می‌شود.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'wpw_shop_' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_MAXTTL', 86400 );

کوتاه بودن WP_REDIS_TIMEOUT تصمیم مهمی است. اگر سرویس کش از کار بیفتد، درخواست‌ها نباید دقیقه‌ها منتظر بمانند؛ یک ثانیه سقف معقولی است تا سایت به مسیر عادی خودش برگردد. همچنین WP_REDIS_MAXTTL سقف عمر کلیدها را محدود می‌کند و از انباشت دادهٔ قدیمی جلوگیری می‌کند.

برای سایت‌های چندگانه (Multisite) یا چند سایت روی یک سرور، جداسازی پیشوند و شمارهٔ دیتابیس از واجبات است. دو سایت که یک پیشوند و یک دیتابیس را به اشتراک بگذارند، کلیدهای یکسان تولید می‌کنند و می‌توانند دادهٔ یکدیگر را بخوانند یا خراب کنند.

استفادهٔ درست از کش در کد افزونه و قالب

بخش عمدهٔ سود کش پایدار از توابع خود وردپرس و افزونه‌ها به‌دست می‌آید، اما اگر کد سفارشی با کوئری سنگین دارید، می‌توانید آن را هم به کش بسپارید. الگوی صحیح ساده است: کلید بسازید، کش را بخوانید، در صورت نبود مقدار کوئری را اجرا کنید و نتیجه را با می‌عاد مشخص بنویسید.

function wpw_get_top_products( $limit = 5 ) {
    $limit     = absint( $limit );
    $cache_key = 'top_products_' . $limit;
    $cached    = wp_cache_get( $cache_key, 'wpw_shop' );

    if ( false !== $cached ) {
        return $cached;
    }

    $products = wc_get_products(
        array(
            'limit'   => $limit,
            'orderby' => 'popularity',
            'order'   => 'DESC',
            'status'  => 'publish',
        )
    );

    wp_cache_set( $cache_key, $products, 'wpw_shop', 30 * MINUTE_IN_SECONDS );

    return $products;
}

سه نکته در این قطعه کد مهم است. اول، کلید کش شامل متغیرهای ورودی ($limit) است تا نتیجهٔ درخواست‌های متفاوت قاطی نشود. دوم، شرط false !== $cached با مقایسهٔ سختگیرانه نوشته شده؛ اگر بی‌دقت بنویسید ! $cached، هر مقدار خالی یا صفر باعث نادیده‌گرفتن کش می‌شود. سوم، نام گروه کش یکتا انتخاب شده است تا پاک‌سازی هدفمند ممکن باشد.

یک قانون ساده همیشه یادتان بماند: هر تابعی که قرار است با تگ‌های HTML یا اطلاعات خصوصی کاربر کار کند را کش نکنید. شناسهٔ کاربر، توکن‌ها، سبد خرید و دادهٔ نشست، نمونه‌های بدیهی هستند. اگر برای این موارد کلید بسازید، باید شناسهٔ کاربر را هم در کلید بگنجانید تا مرز بین کاربران حفظ شود.

کش شیء در ووکامرس و صفحات پرترافیک

در فروشگاه‌های ووکامرس، فشار کوئری‌ها در جاهای مشخصی متمرکز است: فهرست محصولات، شمارش موجودی، امتیازها و محاسبهٔ مالیات. کش شیء این بار را کاهش می‌دهد، ولی دو نکتهٔ حیاتی هم دارد.

نخست، سبد خرید و نشست کاربر هرگز نباید به‌صورت مشترک کش شوند. ووکامرس این موضوع را با کلیدهای اختصاصی مدیریت می‌کند، اما اگر روی آن کد اضافه نوشته‌اید، مراقب باشید دادهٔ کاربر را کنار دادهٔ عمومی نگه‌دارید. دوم، پس از تغییر موجودی یا ذخیرهٔ سفارش، باید کلیدهای مرتبط ابطال شوند. اگر این کار انجام نشود، به اصطلاح با «کش کهنه» روبه‌رو می‌شوید: صفحه چیزی نشان می‌دهد که دیگر درست نیست.

به همین دلیل در فروشگاه‌ها پیشنهاد می‌شود ابطال کش را در هوک‌های مربوط به ذخیرهٔ محصول و سفارش پیاده کنید؛ ساختار هوک‌ها در وردپرس در مقالهٔ هوک در وردپرس چیست؟ توضیح داده شده است. همچنین اگر با هشدارهای ناسازگاری افزونه‌ها در ووکامرس درگیر هستید، مرور راهنمای رفع هشدار ناسازگاری HPOS در ووکامرس کمک می‌کند، چون رفتار کش با ذخیره‌سازی سفارش‌ها گره خورده است.

اندازه‌گیری نتیجه و مدیریت پاک‌سازی

بدون اندازه‌گیری، نمی‌توان گفت کش مؤثر بوده یا فقط پیچیدگی اضافه کرده است. سه ابزار کاربردی در دسترس شماست: شمارندهٔ کوئری، آمار خود Redis و ابزار پایش سرور.

چگونه بفهمیم کش واقعاً کار می‌کند؟

افزونه‌های پروفایلر و عیب‌یابی مثل Query Monitor تعداد کوئری‌های هر صفحه و زمان اجرای آن‌ها را نشان می‌دهند. اگر کش پایدار درست کار کند، تعداد و زمان کوئری‌های تکراری در بازدیدهای بعدی کاهش می‌یابد. از سمت سرور هم می‌توانید نرخ برخورد کش را از خروجی آمار Redis ببینید:

redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 DBSIZE

فیلد keyspace_hits در برابر keyspace_misses تصویر خوبی از نسبت برخورد می‌دهد. نسبت پایین به‌خودی‌خود بد نیست؛ اگر مدت عمر کلیدها کوتاه باشد یا داده زیاد تغییر کند، این عدد طبیعی است. مهم این است که الگو را در طول زمان و در شرایط واقعی ترافیک بسنجید، نه فقط در یک بازدید آزمایشی.

پاک‌سازی، ابطال و ابزارهای خط فرمان

پاک‌سازی کل کش در سایت‌های بزرگ، عملیاتی سنگین است، چون یک‌بار دیگر همهٔ داده از دیتابیس خوانده می‌شود. ترجیح دهید به‌جای flush کلی، گروه‌های محدود را ابطال کنید. برای این کار از خط فرمان وردپرس هم می‌توانید استفاده کنید:

wp cache get wpw_home_stats wpw_reports
wp cache flush
wp redis status
wp redis enable
wp redis disable

پس از فعال‌سازی، همیشه از سایت خارج شوید و در حالت مهمان و در حالت کاربر واردشده هر دو را بررسی کنید. بسیاری از مشکلات کش فقط برای کاربران واردشده ظاهر می‌شود، چون آن‌ها مسیر کد متفاوتی را طی می‌کنند.

خطاهای رایج و نکات امنیتی

پس از فعال‌سازی کش پایدار، سه دستهٔ خطا بیشتر از همه دیده می‌شود.

دادهٔ کهنه و نمایش اطلاعات قدیمی

اگر مهلت انقضای یک کلید را بیش از حد بلند بگذارید، تغییرات محتوا با تأخیر به کاربر می‌رسد. راه‌حل، ابطال صریح کلید در لحظهٔ ذخیرهٔ داده است، نه فقط کوتاه کردن مدت انقضا. برای فهرست‌ها و شمارنده‌ها، عمر کوتاه‌تر و برای داده‌های مرجع، عمر بلندتر منطقی است.

دادهٔ کاربر و مرزهای امنیتی

هرگز اطلاعات حساس را در کش مشترک نگذارید. اگر ناچار به کش‌کردن چیزی هستید که با کاربر گره خورده، شناسهٔ کاربر را بخشی از کلید کنید و مهلت آن را کوتاه نگه دارید. همچنین کلید Redis و اطلاعات اتصال را در مخزن عمومی کد قرار ندهید و از متغیر محیطی یا فایل پیکربندی محافظت‌شده استفاده کنید.

دسترسی شبکه‌ای و پشتیبان‌گیری

سرویس کش باید فقط از محلی که سایت در آن اجرا می‌شود قابل دسترسی باشد. اگر Redis را روی پورت عمومی باز بگذارید و رمز هم تعیین نکنید، هر کسی می‌تواند دادهٔ سایت شما را بخواند یا پاک کند. علاوه بر bind، در صورت نیاز به اتصال از سرور دیگر، رمز قوی و قواعد فایروال را فراموش نکنید. در نهایت، کش را در پشتیبان‌گیری وارد نکنید؛ چون دادهٔ موقت است و بازگردانی آن بی‌فایده یا حتی مضر است. برای ساختار مرتب نگه‌داشتن سایت، مقالهٔ چک‌لیست کارهای ضروری در تعمیر و نگهداری وردپرس چارچوب خوبی ارائه می‌دهد.

چه زمانی کش شیء کافی نیست؟

کش شیء یک لایه از چند لایه است. اگر سرور شما در بارگذاری فایل‌های ایستا کند است، کش پایدار آن را حل نمی‌کند؛ برای تصاویر و رسانه‌ها باید به سراغ قابلیت Lazy load و بهینه‌سازی تصاویر بروید.

اگر کوئری سنگینی دارید که هر بار نتیجهٔ متفاوتی می‌دهد، کش کمکی نمی‌کند؛ باید ایندکس دیتابیس، ساختار کوئری و حجم جداول را بررسی کنید. اگر خروجی HTML برای مهمان‌ها ثابت است، کش صفحه سریع‌تر از کش شیء پاسخ می‌دهد. بهترین نتیجه از ترکیب چند لایه به دست می‌آید، اما هر لایه باید با اندازه‌گیری مستقل ارزیابی شود.

چک‌لیست اجرایی راه‌اندازی کش شیء

• ظرفیت آزاد رم سرور و سقف مصرف سرویس کش را تعیین کنید.
• Redis یا Memcached را متناسب با زیرساخت انتخاب و روی حلقهٔ محلی محدود کنید.
• افزونهٔ PHP مربوط را برای همان نسخهٔ PHP سایت نصب کنید و سرویس را تست کنید.
• پیشوند کلیدها را برای هر سایت جداگانه و یکتا تنظیم کنید.
• مهلت اتصال را کوتاه نگه دارید تا قطعی کش، سایت را از کار نیندازد.
• در کد سفارشی از wp_cache_get و wp_cache_set با مقایسهٔ سختگیرانه استفاده کنید.
• ابطال کش را در هوک‌های ذخیرهٔ محصول، سفارش و تنظیمات پیاده کنید.
• دادهٔ کاربر و اطلاعات حساس را در کش مشترک قرار ندهید.
• نتیجه را با پروفایلر و آمار Redis در ترافیک واقعی بسنجید.
• روش بازگشت امن (غیرفعال کردن افزونه و حذف drop-in) را از قبل بدانید.

کش پایدار یک تنظیم «یک‌بار برای همیشه» نیست. با افزودن افزونهٔ جدید، تغییر قالب یا مهاجرت سرور باید دوباره بازبینی شود. اگر این کار را به بخشی از روال نگهداری تبدیل کنید، احتمال روبه‌رو شدن با دادهٔ کهنه و خطاهای عجیب به‌شدت کاهش می‌یابد.