Varnish برای کش فروشگاه یکی از آن انتخاب‌هایی است که وقتی از سطح راه‌اندازی اولیه عبور می‌کنی و به reverse proxy، VCL (Varnish Configuration Language یا زبان پیکربندی وارنیش)، مدیریت سبد خرید و شرایط پیک ترافیک می‌رسی، ماهیت کاملاً متفاوتی پیدا می‌کند. در چند پروژه فروشگاهی که از Varnish استفاده می‌کردند، یک الگوی مشخص دیده‌ام: سایت‌هایی که تیم فنی داشتند و تنظیمات دقیق اعمال می‌کردند، در ترافیک بالا پایدار ماندند؛ سایت‌هایی که فقط Varnish را نصب کرده بودند، در اولین روز پیک، سبد خرید مشتریان را به‌هم ریختند.

Varnish یک HTTP accelerator یا همان reverse proxy کش است که درخواست‌های HTTP را قبل از رسیدن به وب‌سرور اصلی (Apache یا Nginx) کش می‌کند. این لایه، می‌تواند سرعت پاسخ‌دهی را چند برابر کند و فشار روی PHP-FPM و دیتابیس را به‌شدت کاهش دهد. اما برای فروشگاه‌های آنلاین که سبد خرید، Checkout و پروفایل کاربر دارند، Varnish باید با دقت پیکربندی شود تا داده‌ی خصوصی مشتریان کش نشود.

Varnish برای کش فروشگاه؛ نقطه شروع تصمیم

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

در تجربه‌ی کاری، فروشگاه‌هایی که از Varnish استفاده کرده‌اند، در یکی از این سه دسته قرار می‌گیرند:

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

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

Varnish یک شمشیر دولبه است: با پیکربندی درست، سرعت چند برابر؛ با پیکربندی اشتباه، داده‌ی خصوصی مشتریان را در معرض نمایش قرار می‌دهد.

در تجربه‌ی کاری به این نتیجه رسیده‌ام که Varnish برای فروشگاه‌های بزرگ با ترافیک بالا ارزشمند است، اما برای فروشگاه‌های کوچک، ممکن است هزینه‌ی نگهداری آن توجیه‌پذیر نباشد. مقاله‌ی Server-Level Caching می‌تواند در درک این استراتژی کمک کند.

Varnish دقیقاً چیست؟

Varnish یک HTTP accelerator است که چند کار انجام می‌دهد:

کارکرد توضیح مکانیزم
کش HTTP ذخیره‌ی پاسخ‌های HTTP In-Memory Cache
Reverse Proxy واسطه بین کاربر و وب‌سرور درخواست به Backend
Load Balancing توزیع درخواست بین Backendها Director
ESI Edge Side Includes ترکیب محتوای کش‌شده و زنده
Purge حذف محتوای کش‌شده PURGE Request

این ساختار، Varnish را از یک کش ساده متمایز می‌کند. مقاله‌ی Cache Invalidation می‌تواند در درک کمک کند.

Reverse Proxy و معماری Varnish

Reverse Proxy، یکی از مهم‌ترین بخش‌های معماری Varnish است:

  • کاربر → Varnish (پورت ۸۰) → Backend (پورت ۸۰۸۰)
  • Varnish درخواست را بررسی می‌کند
  • اگر در کش باشد، پاسخ مستقیم داده می‌شود
  • اگر در کش نباشد، به Backend فرستاده می‌شود
  • پاسخ Backend در کش ذخیره می‌شود

در تجربه‌ی کاری، معماری Varnish نیازمند بازطراحی لایه‌ی وب‌سرور است. وب‌سرور اصلی (Apache یا Nginx) باید به پورت غیراستاندارد منتقل شود و Varnish در پورت ۸۰ قرار گیرد. مقاله‌ی بهبود عملکرد سرور می‌تواند راهنمای خوبی باشد.

VCL و زبان پیکربندی Varnish

VCL، یکی از مهم‌ترین بخش‌های Varnish است:

  • زبان پیکربندی اختصاصی Varnish
  • تعریف قوانین کش
  • تعریف قوانین عبور (Pass)
  • تعریف قوانین حذف (Purge)
  • تعریف قوانین Backend

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

sub vcl_recv {
    # Pass admin, cart, checkout, my-account
    if (req.url ~ "^/(wp-admin|wp-login.php|cart|checkout|my-account)") {
        return (pass);
    }
    # Remove cookies for static assets
    if (req.url ~ ".(css|js|png|jpg|jpeg|gif|ico|svg|webp|avif)$") {
        unset req.http.cookie;
    }
    # Pass if has WooCommerce cookies
    if (req.http.Cookie ~ "woocommerce_") {
        return (pass);
    }
}

Cache Hit و Cache Miss در فروشگاه

Cache Hit و Cache Miss، دو مفهوم کلیدی در Varnish هستند:

  • Cache Hit — پاسخ در کش موجود است، سریع برگردانده می‌شود
  • Cache Miss — پاسخ در کش نیست، از Backend گرفته می‌شود
  • Cache Pass — درخواست به Backend فرستاده می‌شود و کش نمی‌شود
  • Cache Hit Ratio — نسبت درخواست‌های Hit به کل

در تجربه‌ی کاری، Cache Hit Ratio مناسب برای فروشگاه‌ها بین ۷۰٪ تا ۹۰٪ است. مقاله‌ی Edge Caching می‌تواند راهنمای خوبی باشد.

سبد خرید و داده خصوصی در Varnish

سبد خرید و داده‌ی خصوصی، حساسترین بخش Varnish در فروشگاه است:

  • سبد خرید باید Pass شود، نه کش
  • Checkout باید Pass شود
  • پروفایل کاربر باید Pass شود
  • پیشخوان باید Pass شود
  • داده‌ی شخصی مشتری نباید کش شود

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

Varnish و ووکامرس

Varnish و ووکامرس، ترکیبی است که نیازمند پیکربندی دقیق است:

  • Cookies ووکامرس (woocommerce_cart_hash، woocommerce_items_in_cart)
  • Nonces وردپرس
  • Sessionهای مشتری
  • پارامترهای Add-to-Cart
  • پارامترهای AJAX

در تجربه‌ی کاری، برای Varnish و ووکامرس، باید در VCL قوانین خاصی برای Cookies و پارامترهای ووکامرس تعریف شود. مقاله‌ی عملکرد ووکامرس می‌تواند راهنمای خوبی باشد.

راه‌اندازی Varnish برای فروشگاه

راه‌اندازی Varnish برای فروشگاه شامل چند مرحله است:

  1. نصب Varnish در سرور
  2. تغییر پورت وب‌سرور به ۸۰۸۰
  3. پیکربندی Varnish برای پورت ۸۰
  4. نوشتن VCL مناسب
  5. پیکربندی Backend
  6. تست عملکرد سایت
  7. تست سبد خرید و Checkout
  8. پیکربندی Purge
  9. پایش Cache Hit Ratio

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

Purge و Invalidation در Varnish

Purge و Invalidation، یکی از مهم‌ترین بخش‌های Varnish است:

  • حذف محتوای کش‌شده در زمان به‌روزرسانی محتوا
  • Purge خودکار با WordPress Plugin (مثل Varnish HTTP Purge)
  • Purge دستی با درخواست PURGE
  • Ban برای حذف گروهی
  • Grace Mode برای پاسخ در زمان Backend خاموش

در تجربه‌ی کاری، نبود Purge مناسب، رایج‌ترین دلیل نمایش محتوای قدیمی در فروشگاه است. مقاله‌ی Cache Invalidation می‌تواند راهنمای خوبی باشد.

تأثیر Varnish بر سرعت و مقیاس

تأثیر Varnish بر سرعت و مقیاس، یکی از مهم‌ترین دلایل استفاده از این ابزار است:

  • کاهش TTFB (Time To First Byte)
  • کاهش فشار روی PHP-FPM
  • کاهش کوئری‌های دیتابیس
  • افزایش همزمانی (Concurrency)
  • کاهش هزینه‌ی سرور

در تجربه‌ی کاری، Varnish در فروشگاه‌های با ترافیک بالا، می‌تواند ظرفیت سرور را چند برابر کند. مقاله‌ی عملکرد فروشگاه در مقیاس می‌تواند راهنمای خوبی باشد.

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

در تجربه‌ی کاری، این اشتباهات بیشترین تکرار را داشته‌اند:

  1. نبود تیم فنی — راه‌اندازی Varnish بدون تخصص
  2. نبود تنظیمات — استفاده از VCL پیش‌فرض
  3. نبود تست — تست نکردن سبد خرید و Checkout
  4. کش شدن سبد خرید — نمایش سبد اشتباه به مشتری
  5. نبود Purge — نمایش محتوای قدیمی
  6. نبود Grace Mode — قطعی در زمان Backend خاموش

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

پرسش‌های پرتکرار درباره Varnish

Varnish چیست و چه کاربردی در فروشگاه دارد؟

Varnish یک HTTP accelerator یا reverse proxy کش است که درخواست‌های HTTP را قبل از رسیدن به وب‌سرور کش می‌کند. برای فروشگاه‌های با ترافیک بالا، این ابزار یکی از مؤثرترین راهکارها برای بهبود سرعت و مقیاس است.

آیا Varnish با ووکامرس سازگار است؟

بله، اما نیازمند VCL خاص و قوانین دقیق برای Cookies و پارامترهای ووکامرس است. بدون این قوانین، Varnish می‌تواند سبد خرید مشتریان را خراب کند.

تفاوت Varnish و Nginx Cache چیست؟

Varnish در حافظه (RAM) کش می‌کند و سریع‌تر است. Nginx Cache روی دیسک کش می‌کند و پایدارتر است. برای فروشگاه‌های بزرگ، Varnish توصیه می‌شود.

چطور Cache Hit Ratio Varnish را افزایش دهیم؟

با تنظیم دقیق VCL، حذف Cookies غیرضروری، کش کردن صفحات عمومی و Pass کردن صفحات خصوصی.

آیا Varnish جایگزین کش پلاگین وردپرس است؟

نه. Varnish مکمل کش پلاگین است. بهترین رویکرد، ترکیب Varnish با یک افزونه‌ی کش مثل WP Rocket یا LiteSpeed Cache است.

آیا Varnish از HTTPS پشتیبانی می‌کند؟

بله، اما به‌طور مستقیم. Varnish به‌تنهایی SSL/TLS را مدیریت نمی‌کند و نیاز به یک لایه‌ی دیگر (مثل Nginx یا Hitch) دارد.

آیا Varnish برای فروشگاه‌های کوچک مناسب است؟

معمولاً نه. Varnish برای فروشگاه‌های بزرگ با ترافیک بالا مناسب است، چون هزینه‌ی نگهداری آن قابل توجه است.

نگاه مهندسی پیشرفته به Varnish

از منظر مهندسی ارشد، Varnish یک ابزار حرفه‌ای است که در معماری فروشگاه چند لایه را پوشش می‌دهد: لایه‌ی کش HTTP، لایه‌ی reverse proxy، لایه‌ی load balancing، لایه‌ی ESI و لایه‌ی Purge.

معیارهای کلیدی برای ارزیابی:

  • نرخ Cache Hit
  • پایداری در ترافیک بالا
  • سرعت Purge و Invalidation
  • هزینه‌ی کل مالکیت در بازه‌ی سه‌ساله
  • پایداری تیم فنی در بلندمدت

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

اگر این تجربه را در یک پروژه‌ی واقعی داشته‌اید، برای من جالب است بدانم کدام بخش بیشترین زمان را از شما گرفت؛ نوشتن VCL یا پیکربندی Purge؟ دیدگاه خودتان را بنویسید.