Nginx FastCGI Cache برای وردپرس چطور پیکربندی می‌شود؟

پیکربندی Nginx FastCGI Cache برای وردپرس یعنی ذخیره پاسخ‌های ساخته‌شده توسط PHP-FPM در لایه وب‌سرور، به‌گونه‌ای که درخواست‌های بعدی پیش از ورود به PHP پاسخ بگیرند.

این لایه کش، پیشرفته‌ترین گزینه برای سایت‌های پربازدید است، چون هزینه ورود به وردپرس را برای هر درخواست تکرارشونده حذف می‌کند.

سه جزء اصلی باید با دقت تنظیم شوند: مسیر و ناحیه کش، کلید کش و قواعد استثنا برای پاسخ‌های پویا.

انتخاب اشتباه در هر یک از این سه، یا باعث نمایش محتوای شخصی به کاربر دیگر می‌شود یا مزیت کش را از بین می‌برد.

هدف این نوشته، رسیدن از پیکربندی خام به تنظیمی است که در محیط تولید پایدار بماند.

در پروژه‌های پربازدید، تفاوت میان یک سرور پایدار و یک سرور پرتنش، اغلب در چند خط تنظیم نهفته است که کسی وقت نکرده درباره‌شان تصمیم بگیرد. FastCGI Cache یکی از همین چند خط است: زمانی که درست تنظیم شود، می‌تواند سرور متوسطی را به سایتی سریع تبدیل کند؛ زمانی که اشتباه تنظیم شود، می‌تواند دردسرهایی بسازد که یافتن ریشه‌شان روزها طول بکشد.

FastCGI Cache دقیقاً چه چیزی را ذخیره می‌کند

وقتی مرورگر صفحه‌ای از وردپرس را درخواست می‌کند، Nginx درخواست را به PHP-FPM می‌سپارد. PHP-FPM اسکریپت‌های وردپرس را اجرا می‌کند، کوئری‌های پایگاه داده را می‌فرستد، خروجی HTML را می‌سازد و آن را به Nginx برمی‌گرداند. Nginx هم آن را به مرورگر می‌فرستد.

FastCGI Cache این خروجی HTML را در دیسک ذخیره می‌کند. درخواست بعدی برای همان صفحه، پیش از رسیدن به PHP-FPM پاسخ می‌گیرد. هزینه‌ای که حذف می‌شود، شامل بارگذاری هسته وردپرس، اجرای افزونه‌ها، کوئری‌های پایگاه داده و ساخت قالب است.

این تفاوت با آنچه در سطح PHP اتفاق می‌افتد، بنیادین است. OPcache کد کامپایل‌شده را نگه می‌دارد، اما اجرای منطق وردپرس را حذف نمی‌کند. FastCGI Cache کل اجرای منطق را برای پاسخ‌های تکراری حذف می‌کند.

نتیجه عملی این تفاوت در زمان پاسخ دیده می‌شود. تفاوت میان چند صد میلی‌ثانیه پاسخ از PHP-FPM و چند ده میلی‌ثانیه پاسخ از FastCGI Cache، در معیار TTFB (Time To First Byte) کاملاً مشهود است و مستقیماً روی کاهش زمان TTFB اثر می‌گذارد.

هر درخواستی که به PHP-FPM نرسد، هزینه‌ای است که سرور پرداخت نمی‌کند.

تفاوت با کش افزونه‌ای

افزونه‌های کش وردپرس، خروجی HTML را در سطح خود وردپرس ذخیره می‌کنند. یعنی هر درخواست همچنان به PHP-FPM می‌رسد، هسته وردپرس بارگذاری می‌شود، افزونه کش اجرا می‌شود و سپس نسخه ذخیره‌شده به کاربر بازگردانده می‌شود. هزینه این مسیر نسبت به حالت بدون کش پایین‌تر است، اما صفر نیست.

FastCGI Cache یک قدم جلوتر می‌رود. پاسخ پیش از ورود به وردپرس سرو می‌شود، بدون بارگذاری هسته، بدون اجرای افزونه‌ها و بدون کوئری به پایگاه داده. این تفاوت در سایت‌های پربازدید به صرفه‌جویی چشمگیر منابع تبدیل می‌شود.

نکته مهم این است که این دو مکمل یکدیگرند، نه جانشین. افزونه کش منطق سطح محتوا را مدیریت می‌کند: تفکیک کاربران، استثنای صفحات شخصی، مدیریت نسخه‌بندی و پاک‌سازی هدفمند. FastCGI Cache لایه انتقال را بهینه می‌کند.

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

پیکربندی پایه: مسیر، ناحیه و کلید

ساختار پیکربندی FastCGI Cache در فایل تنظیمات Nginx انجام می‌شود. سه دستور کلیدی وجود دارد که پایه کار را می‌سازند.

fastcgi_cache_path /var/cache/nginx/wpk levels=1:2 keys_zone=wpk:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;

دستور اول ناحیه کش را تعریف می‌کند. پارامتر levels=1:2 ساختار دایرکتوری دو سطحی می‌سازد که تعداد فایل در هر دایرکتوری را محدود می‌کند. پارامتر keys_zone حافظه اختصاصی برای نگه‌داشتن کلیدها را تعیین می‌کند. پارامتر inactive تعیین می‌کند پس از چند دقیقه عدم استفاده، یک ورودی از کش حذف شود. پارامتر max_size سقف حجم کل کش را مشخص می‌کند.

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

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

دستور سوم رفتار کش در زمان خطای سرور مبدأ را تعیین می‌کند. با پارامتر use_stale، در زمان بروز خطا در PHP-FPM، نسخه قدیمی کش‌شده به کاربر بازگردانده می‌شود. این ویژگی، پایداری سایت را در زمان‌های پرمخاطره بالا می‌برد.

طراحی کلید کش

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

کلید استاندارد شامل چهار بخش است: طرح (HTTP یا HTTPS)، متد درخواست، دامنه و مسیر کامل درخواست. این ترکیب، پاسخ‌ها را بر اساس یکتایی مسیر تفکیک می‌کند.

مسائل وقتی پیچیده‌تر می‌شوند که سایت نسخه‌های متفاوتی برای موبایل و دسکتاپ سرو کند یا محتوای متفاوتی بر اساس زبان کاربر نمایش دهد. در چنین حالتی، کلید کش باید شامل پارامترهای اضافه باشد تا پاسخ‌های متفاوت با یک کلید یکسان ذخیره نشوند.

map $http_user_agent $wpk_device {
    default "desktop";
    "~*mobile|android|iphone" "mobile";
}

fastcgi_cache_key "$scheme$request_method$host$request_uri$wpk_device";

نکته دیگر، حضور پارامترهای کوئری در کلید است. اگر پارامترهای کوئری در کلید لحاظ نشوند، درخواست‌های با پارامترهای متفاوت، یک پاسخ یکسان می‌گیرند. این رفتار در بعضی سناریوها مطلوب و در بعضی نامطلوب است.

در سایت‌هایی که از پارامترهای UTM برای ردیابی تبلیغات استفاده می‌کنند، حذف این پارامترها از کلید منطقی است، چون اثر محتوایی ندارند. اما در سایت‌های فروشگاهی که پارامترهای فیلتر محصول را حمل می‌کنند، حضور این پارامترها ضروری است.

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

قواعد استثنا و پاسخ‌های پویا

بخش بزرگی از پاسخ‌های وردپرس ماهیت شخصی دارند. صفحه‌های پیشخوان، سبد خرید، تسویه حساب، پروفایل کاربر و درخواست‌های AJAX باید از کش مستثنا شوند. اگر این استثناها اعمال نشوند، خطر نمایش داده شخصی به کاربر دیگر جدی است.

مکانیزم Nginx برای این کار استفاده از دو متغیر است: fastcgi_cache_bypass برای عبور از خواندن کش و fastcgi_no_cache برای جلوگیری از نوشتن در کش. معمولاً این دو با یک مقدار مشترک کنترل می‌شوند.

set $skip_cache 0;

if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }

if ($request_uri ~* "/wp-admin/|/wp-login.php|/cart/|/checkout/|/my-account/") {
    set $skip_cache 1;
}

if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
}

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

ترتیب این قواعد اهمیت دارد. هر قاعده، متغیر مشترک را بررسی می‌کند و در صورت تطابق، آن را روی یک تنظیم می‌کند. اگر قواعد به‌درستی مرتب نشوند، ممکن است یک قاعده، اثر قاعده قبلی را از بین ببرد.

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

در سایت‌های فروشگاهی، لیست صفحات استثنا طولانی‌تر است. صفحه‌های محصول می‌توانند کش شوند، اما نمایش قیمت و موجودی در آن‌ها ممکن است نیازمند استثنا باشد. رویکرد دقیق این کار در بهینه‌سازی سرعت ووکامرس به‌تفصیل بررسی شده است.

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

پاک‌سازی هدفمند با PURGE

وقتی محتوایی تغییر می‌کند، نسخه کش‌شده آن باید بی‌اعتبار شود. Nginx به‌طور پیش‌فرض از درخواست‌های HTTP با متد PURGE پشتیبانی نمی‌کند، اما این مکانیزم با یک بلوک ساده فعال می‌شود.

location ~ /purge(/.*) {
    allow 127.0.0.1;
    deny all;
    fastcgi_cache_purge wpk "$scheme$request_method$host$1";
}

با این پیکربندی، ارسال درخواست PURGE به آدرس مشخص، نسخه کش‌شده آن آدرس را حذف می‌کند. توجه به محدودیت دسترسی ضروری است؛ اجازه عمومی به این متد، امکان سوءاستفاده فراهم می‌کند.

در سمت وردپرس، این مکانیزم باید در رویدادهای مناسب فراخوانی شود. هوک save_post، deleted_post، edited_term و updated_option نقاط طبیعی برای این کار هستند.

add_action( "save_post", function ( $post_id ) {
    if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
        return;
    }
    $url = get_permalink( $post_id );
    $path = parse_url( $url, PHP_URL_PATH );
    wp_remote_request( "http://127.0.0.1/purge" . $path, array( "method" => "PURGE" ) );
}, 10, 1 );

نکته مهم این است که پاک‌سازی کش لایه FastCGI باید با پاک‌سازی سایر لایه‌ها هماهنگ باشد. اگر فقط این لایه پاک شود و کش شیء یا لایه CDN دست‌نخورده بماند، کاربر ممکن است همچنان نسخه قدیمی را ببیند. مکانیزم‌های بی‌اعتبارسازی در لایه‌های دیگر در بی‌اعتبارسازی کش در وردپرس به‌تفصیل آمده است.

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

وردپرس از FastCGI Cache به‌طور بومی پشتیبانی نمی‌کند، چون این مکانیزم در لایه وب‌سرور تعریف شده است. اما این بدان معنا نیست که وردپرس نمی‌تواند با این لایه همکاری کند.

رویکرد اول، استفاده از افزونه‌های تخصصی است. این افزونه‌ها مکانیزم‌های لازم را در سمت وردپرس پیاده می‌کنند و با FastCGI Cache ارتباط برقرار می‌کنند. در عمل، انتخاب افزونه‌ای که با این لایه هماهنگ باشد، بخشی از تصمیم‌گیری کلی در بهترین افزونه‌های کش وردپرس است.

رویکرد دوم، پیاده‌سازی دستی مکانیزم‌ها با استفاده از هوک‌های وردپرس است. این رویکرد کنترل دقیق‌تری می‌دهد اما نیازمند دانش فنی است.

در هر دو رویکرد، سه نکته اصلی باید رعایت شود. اول، هدر X-FastCGI-Cache باید در پاسخ‌ها قرار بگیرد تا وضعیت کش قابل تشخیص باشد. دوم، پاک‌سازی هدفمند باید در رویدادهای تغییر محتوا انجام شود. سوم، صفحات شخصی باید در سمت Nginx به‌طور کامل استثنا شوند، نه فقط در سمت وردپرس.

در سایت‌هایی که از قالب اختصاصی استفاده می‌کنند، ممکن است لازم باشد بخش‌هایی از قالب از کش مستثنا شوند. مثلاً بخش نمایش آخرین دیدگاه‌ها یا بخش نمایش داده‌های کاربر. این استثناها باید در سطح Nginx یا در سطح وردپرس اعمال شوند، نه در سطح قالب.

پیکربندی برای ووکامرس

فروشگاه‌های ووکامرس بدترین سناریو برای FastCGI Cache هستند، چون بخش بزرگی از صفحات ماهیت شخصی دارند و بخش دیگری به‌شدت پویا هستند. با این حال، پیکربندی درست می‌تواند بخش قابل توجهی از بار را کاهش دهد.

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

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

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

if ($cookie_woocommerce_items_in_cart) { set $skip_cache 1; }
if ($cookie_woocommerce_cart_hash) { set $skip_cache 1; }
if ($request_uri ~* "/product/.*?(add-to-cart|variation_id)") { set $skip_cache 1; }

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

هماهنگی با لایه CDN

وقتی سایت از شبکه توزیع محتوا استفاده می‌کند، هماهنگی میان این لایه و FastCGI Cache اهمیت دوچندان پیدا می‌کند. اگر سیاست‌های این دو لایه با هم هماهنگ نباشند، رفتار نهایی مبهم و غیرقابل پیش‌بینی می‌شود.

هدرهای کش که Nginx ارسال می‌کند، توسط لایه CDN تفسیر می‌شوند. اگر این هدرها با سیاست لایه FastCGI متناقض باشند، لایه CDN ممکن است رفتاری متفاوت نشان دهد.

راه‌حل استاندارد این است که FastCGI Cache به‌عنوان لایه دوم عمل کند و هدرهای ارسالی به CDN، سیاست کش لبه را تعیین کنند. یعنی لایه CDN اولین نگهدارنده پاسخ و FastCGI Cache پشتوانه آن باشد.

هدر X-FastCGI-Cache در این معماری مفید است، چون نشان می‌دهد پاسخ از کدام لایه سرو شده است. اگر در زمان عیب‌یابی، مقدار این هدر HIT باشد، پاسخ از FastCGI آمده است. اگر MISS باشد، پاسخ از PHP-FPM آمده و در کش ذخیره شده است.

پیکربندی کامل این هدرها و سیاست‌های متناظر، موضوعی است که در تنظیم هدرهای کش در وردپرس به‌تفصیل آمده است. رعایت این اصول در پروژه‌های چندلایه ضروری است.

Stale-While-Revalidate و الگوهای پیشرفته

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

fastcgi_cache_use_stale updating error timeout invalid_header http_500 http_503;
fastcgi_cache_background_update on;
fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 5s;

پارامتر use_stale تعیین می‌کند در چه شرایطی نسخه قدیمی سرو شود. با فعال‌بودن این پارامتر، در زمان به‌روزرسانی کش یا خطای سرور مبدأ، نسخه قدیمی به کاربر بازگردانده می‌شود.

پارامتر background_update به Nginx اجازه می‌دهد در پس‌زمینه نسخه جدید را از سرور مبدأ دریافت کند. نتیجه، تجربه‌ای است که در آن کاربر هرگز با انتظار روبه‌رو نمی‌شود.

پارامتر cache_lock مکانیزمی برای جلوگیری از Cache Stampede است. وقتی یک صفحه از کش خارج می‌شود، تنها یک فرآیند مجاز به ساخت پاسخ جدید است و بقیه منتظر نتیجه آن می‌مانند. این پارامتر برای صفحات پرترافیک بسیار مهم است.

مسئله Cache Stampede و راه‌حل‌های آن، موضوعی است که در بی‌اعتبارسازی کش در وردپرس به‌تفصیل بررسی شده است. ترکیب قواعد این دو مسیر، یک سیستم کش پایدار می‌سازد.

گرم‌کردن کش پس از استقرار

هر بار که کش پاک می‌شود، سرور با نسخه سرد روبه‌رو می‌شود. اگر این پاک‌سازی با ترافیک واقعی همزمان شود، کاربران هزینه ساخت پاسخ‌های تازه را می‌پردازند. گرم‌کردن کش، این هزینه را از دوش کاربر برمی‌دارد.

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

#!/usr/bin/env bash
URLS=(
  "https://example.com/"
  "https://example.com/blog/"
  "https://example.com/shop/"
)

for u in "${URLS[@]}"; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s  $u
" "$u"
  sleep 0.2
done

ترتیب عملیات Warming اهمیت دارد. نخست، PHP-FPM و OPcache باید گرم شوند. دوم، FastCGI Cache باید گرم شود. سوم، لایه CDN باید از طریق درخواست‌های واقعی نسخه‌های محلی خود را بسازد.

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

هر پاک‌سازی کش، یک فرصت برای Warming است؛ نادیده گرفتن این فرصت، هزینه‌ای است که کاربر می‌پردازد.

پایش و اشکال‌زدایی

پایش درست FastCGI Cache نیازمند سه سطح اندازه‌گیری است. در سطح Nginx، وضعیت کش با هدرهای پاسخ قابل بررسی است. در سطح فایل سیستم، می‌توان حجم کش و نرخ پر شدن آن را اندازه گرفت. در سطح تجربه کاربر، معیارهای زمان پاسخ و نرخ خطا اهمیت دارند.

هدر X-FastCGI-Cache مهم‌ترین ابزار در زمان عیب‌یابی است. مقدار HIT نشان می‌دهد پاسخ از کش آمده، MISS نشان می‌دهد پاسخ تازه ساخته شده، BYPASS نشان می‌دهد درخواست از کش عبور کرده و EXPIRED نشان می‌دهد نسخه کش‌شده منقضی شده بود.

add_header X-FastCGI-Cache $upstream_cache_status;

بررسی این هدر در زمان‌های مختلف و برای آدرس‌های مختلف، تصویر روشنی از رفتار کش ارائه می‌دهد. اگر مقدار آن برای صفحه‌ای که باید کش شود همواره MISS باشد، احتمالاً قواعد استثنا اشتباه تنظیم شده‌اند.

ابزارهای پایش سرور می‌توانند میزان بار PHP-FPM را نشان دهند. اگر پس از فعال‌سازی FastCGI Cache، این بار کاهش قابل توجهی نداشته باشد، احتمالاً کلید کش یا قواعد استثنا مشکل دارند.

در سطح تجربه کاربر، معیارهای Core Web Vitals باید اندازه‌گیری شوند. اگر FastCGI Cache درست تنظیم شده باشد، بهبود محسوسی در این معیارها دیده می‌شود. ابزارهای مناسب برای این اندازه‌گیری در ابزارهای تست سرعت سایت معرفی شده‌اند.

جدول تصمیم‌گیری تنظیمات کلیدی

اشتباهات رایج

نخستین اشتباه، کش کردن همه پاسخ‌ها بدون استثنا است. نتیجه، نمایش داده شخصی به کاربر دیگر یا کش شدن پاسخ‌های خطا.

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

سومین اشتباه، فراموش‌کردن پارامترهای کوئری در کلید کش است. اگر این پارامترها در کلید لحاظ نشوند، درخواست‌های متفاوت یک پاسخ مشترک می‌گیرند.

چهارمین اشتباه، نادیده گرفتن هماهنگی با لایه CDN است. اگر هر دو لایه سیاست‌های متفاوتی داشته باشند، رفتار نهایی غیرقابل پیش‌بینی می‌شود.

پنجمین اشتباه، نبود Warming پس از پاک‌سازی است. کاربر اول در هر بازه، هزینه ساخت پاسخ‌های تازه را می‌پردازد.

ششمین اشتباه، بی‌توجهی به پارامترهای Stale است. بدون این پارامترها، در زمان به‌روزرسانی کش یا خطای سرور مبدأ، کاربر با انتظار یا خطا روبه‌رو می‌شود.

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

هشتمین اشتباه، بی‌توجهی به ترکیب با کش شیء است. اگر کش شیء معتبر نباشد، درخواست‌هایی که به PHP-FPM می‌رسند، بار سنگینی روی پایگاه داده می‌گذارند. هماهنگی این دو لایه در مسیر بهینه‌سازی پیشرفته دیتابیس وردپرس پوشش داده می‌شود.

پرسش‌های پرتکرار درباره Nginx FastCGI Cache در وردپرس

آیا FastCGI Cache جایگزین افزونه کش است؟

خیر. این دو در دو لایه مختلف کار می‌کنند و مکمل یکدیگرند. افزونه کش منطق سطح محتوا را مدیریت می‌کند و FastCGI Cache هزینه انتقال و ورود به PHP را حذف می‌کند.

چگونه بفهمم پاسخ از کش سرو شده است؟

هدر X-FastCGI-Cache این اطلاعات را می‌دهد. مقدار HIT نشان می‌دهد پاسخ از کش آمده است. این هدر باید در پیکربندی Nginx اضافه شود و در پاسخ‌ها قابل مشاهده باشد.

چرا برخی صفحات کش نمی‌شوند؟

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

چگونه کش را برای یک URL مشخص پاک کنم؟

با ارسال درخواست PURGE به همان URL. این مکانیزم باید در پیکربندی Nginx فعال شود و از یک آدرس خاص با محدودیت دسترسی پاسخ دهد.

آیا FastCGI Cache روی سئو اثر دارد؟

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

آیا برای سایت کوچک هم FastCGI Cache توصیه می‌شود؟

برای سایت‌های کوچک با ترافیک محدود، افزونه کش معمولاً کافی است. FastCGI Cache اثر خود را در سایت‌های پربازدید یا سایت‌هایی با بار همزمان بالا نشان می‌دهد.

چگونه از Cache Stampede جلوگیری کنم؟

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

آیا باید FastCGI Cache را با پارامترهای Stale تنظیم کنم؟

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

یک نکته برای ادامه مسیر

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

اگر روی پروژه خودتان این مسیر را طی کرده‌اید، خوشحال می‌شوم بدانم کدام بخش بیشترین زمان را گرفت: طراحی کلید کش، پیاده‌سازی قواعد استثنا برای ووکامرس، یا هماهنگ‌سازی با لایه CDN. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر راه‌حل متفاوتی پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد.