Varnish Cache: Nginx ve Apache ile Kurulum

Varnish Cache ile Reverse Proxy Mimarisi Neden Fark Yaratır?

Bir web projesinin trafik kapasitesini değerlendirirken CPU, RAM, disk I/O ve veritabanı yükü birlikte incelenir. Dinamik PHP sitelerinde aynı genel yanıtın tekrar üretildiği istekler yoğunsa, tam sayfa önbellekleme bu işin bir bölümünü azaltabilir. Varnish Cache bu amaçla uygulamanın önüne yerleştirilen seçeneklerden biridir.

Varnish, Nginx veya Apache önünde çalışan bir HTTP reverse proxy ve önbellek sunucusudur. Uygun yanıtları tekrar kullanarak PHP-FPM ve veritabanı işini azaltabilir; TTFB ve istek kapasitesine etkisi ölçülmelidir. WordPress, WooCommerce ve Laravel projelerinde kazanım, ortak önbelleğe uygun yanıtların payına, isabet oranına ve altyapı kaynaklarına bağlıdır.

Bu rehber, bir VPS üzerinde Nginx veya Apache önüne Varnish yerleştirmeyi; portları, VCL kurallarını, WordPress/WooCommerce istisnalarını ve performans ölçümünü birlikte ele alır. Kodlar Varnish Cache 7.6 / VCL 4.1 davranışı temel alınarak hazırlanmıştır. Dağıtım paketinin aynı sürümü kuracağını varsaymayın; kurulu sürümü ve etkin servis tanımını kontrol edin.

Varnish Cache Nedir, Nginx/Apache ile Roller Nasıl Ayrılır?

Varnish’i doğru anlamadan sağlıklı bir kurulum tasarlamak zordur. Varnish bir web sunucusu değil, HTTP reverse proxy ve tam sayfa önbellek motorudur. Backend’den aldığı statik dosya yanıtlarını da önbellekten sunabilir; esas gücü, dinamik sayfaların ortak önbelleğe uygun yanıtlarını saklayarak aynı içeriği isteyen isteklere tekrar cevap vermesindedir.

Temel rol dağılımı

• Varnish: Nginx/Apache’nin önündeki HTTP önbellek katmanıdır; TLS terminatörü veya CDN varsa istemcinin ilk temas noktası bu dış katman olur. HTTP isteklerini karşılar, mümkünse önbellekten (cache) yanıtlar, değilse arkadaki Nginx/Apache’ye iletir.
• Nginx/Apache (backend/origin): Statik dosyaları sunar ve dinamik istekleri PHP-FPM gibi uygulama işleyicilerine aktarır. WordPress, Laravel veya Magento gibi uygulamaların kodu da gerektiğinde veritabanına erişir.

Akış kabaca şöyledir:

• Tarayıcı GET / isteğini gönderir.
• Varnish isteği alır, HTTP header’lara, URL’ye, çerezlere ve tanımlı VCL kurallarına bakarak bu isteğin cache’ten karşılanıp karşılanamayacağına karar verir.
• İstek için kullanılabilir bir yanıt önbellekte varsa, backend’e gitmeden cevap verir (cache hit).
• Önbellek aramasında uygun yanıt bulunamazsa, isteği Nginx/Apache’ye aktarır (cache miss). Backend cevabı geldikten sonra, kurallara göre önbelleğe koyabilir. Önbelleği atlaması gereken istekler ise doğrudan backend’e iletilir.

Bu rol dağılımı sayesinde önbellekten karşılanan istekler için Nginx/Apache & PHP-FPM & veritabanı katmanında yeniden dinamik yanıt üretmek gerekmez. Varsayımsal bir haber sitesinde anasayfa isteklerinin %90’ından fazlası Varnish önbelleğinden karşılanıyorsa, backend’e ulaşan anasayfa isteği sayısı belirgin biçimde azalır. CPU, NVMe disk I/O ve tepki sürelerindeki değişim ise diğer trafik ve darboğazlara bağlıdır. Yüksek trafikli haber ve blog siteleri için hosting ve önbellek stratejileri üzerine yazdığımız rehberde bu etkiyi detaylı örneklerle anlatıyoruz.

HTTP/HTTPS konusu: TLS nerede bitmeli?

Burada ele alınan Varnish Cache 7.6, TLS sonlandırmaz. HTTPS için önünde TLS terminatörü gerekir; iki yerleşim şöyledir:

• Desen 1: TLS terminatörü (ör. Hitch veya Nginx) → Varnish (HTTP) → Nginx/Apache (HTTP)
• Desen 2: Dış tarafta başka bir load balancer/CDN TLS’i bitirir → Varnish’e HTTP olarak gelir → Backend’e HTTP gider

Bu yazıda odak noktamız, Varnish’in Nginx/Apache önünde olduğu klasik reverse proxy senaryosu; dolayısıyla örneklerde HTTP üzerinden konuşacağız. Üretim ortamında ise genellikle Nginx veya Hitch ile TLS terminasyonu yapıp trafik Varnish’e HTTP olarak aktarılır. Buradaki HTTP bağlantıları loopback veya güvenilir, erişimi kısıtlanmış bir özel ağ varsayar; CDN ile origin arasındaki gibi güvenilmeyen ağ geçişlerinde TLS koruması da tasarlanmalıdır. Detaylı TLS ve HTTP/2/HTTP/3 optimizasyonları için HTTP/2 ve HTTP/3 desteğinin SEO ve Core Web Vitals etkilerini anlattığımız rehbere de mutlaka göz atın.

Mimari Tasarım: Tek VPS, Çoklu VPS ve CDN ile Gerçekçi Senaryolar

Varnish’i nereye koyacağınız tamamen iş yükünüzün büyüklüğüne ve mevcut altyapınıza bağlı. İş yükünüze göre değerlendirebileceğiniz üç temel senaryoyu özetleyelim.

1) Tek VPS Üzerinde Hepsi Bir Arada (Küçük/Orta Ölçek)

Tek sunucuda değerlendirilebilecek yerleşim:

• Tek VPS üzerinde Varnish + Nginx veya Apache + PHP-FPM + veritabanı bulunabilir; kaynakları birlikte boyutlandırın.
• HTTP laboratuvar örneğinde Varnish 80, backend yalnızca 127.0.0.1:8080 dinler. Herkese açık HTTPS için Nginx/Hitch 443 → Varnish 127.0.0.1:6081 → backend 127.0.0.1:8080 gibi ayrı bir akış kurulur.

Varsayımsal trafik profili (bir VPS kapasite taahhüdü değildir; kaynak boyutu, önbellek vuruş oranı ve dinamik istek maliyetiyle birlikte değerlendirilmelidir):

• Aylık 300k – 5M sayfa görüntüleme
• Ağırlıklı okuma trafiği (blog, içerik sitesi, basit e-ticaret)
• Yoğun anlarda saniyede 100–300 istek

Bu senaryoda doğru Varnish konfigürasyonu, önbellekten karşılanan isteklerde TTFB’yi azaltabilir; ancak yüksek TTFB sorunlarının sunucu tarafı nedenlerini ayrıca incelemek gerekir. Önbellekleme, yavaş backend işlemlerinin nedenlerini tek başına ortadan kaldırmaz.

2) Ayrı Varnish Katmanı + Ayrı Uygulama Sunucuları (Orta/Büyük Ölçek)

Daha yüksek trafikli yapılarda, özellikle WooCommerce, büyük kataloglu mağazalar ve SaaS panellerinde katmanları ayrı ölçeklemek için aşağıdaki mimari değerlendirilebilir. Varnish’in katkısı, kişiye veya oturuma özel yanıtların değil, ortak önbelleğe uygun yanıtların payına bağlıdır:

• 1 veya daha fazla Varnish sunucusu (VPS veya dedicated)
• Arkada 1–N adet Nginx/Apache + PHP-FPM uygulama sunucusu
• Veritabanı ayrı bir VPS veya dedicated sunucuda

Bu mimaride Varnish aynı zamanda basit bir HTTP load balancer olarak da davranabilir. Birden fazla backend tanımlamak tek başına yük dağıtımı yapmaz; directors VMOD ile seçim politikasını, backend probe ile sağlık kontrolünü yapılandırmanız gerekir. Eğer bu yapıyı daha da ileri taşımak isterseniz, Nginx reverse proxy ve basit load balancer kurulum rehberimizde anlattığımız bazı fikirleri Varnish ile birlikte uygulayabilirsiniz.

3) Varnish + CDN + Edge Önbellekleme (Global Trafik)

Global hedef kitleye hizmet veren projelerde, Varnish’i yalnızca uygulama sunucusunu koruyan bir katman olarak değil, aynı zamanda CDN ile birlikte çalışan bir origin cache ve shield olarak konumlandırabilirsiniz:

• Kullanıcı → CDN → origin TLS terminatörü → Varnish → Nginx/Apache backend.
• CDN ile Varnish arasındaki doğrudan HTTP ancak güvenilir ve erişimi sınırlandırılmış özel yolda düşünülmelidir.

Burada CDN, uygun önbellek isabetlerinde ziyaretçiye yakın yanıt verebilir. Origin erişimini tasarladığınız giriş katmanıyla sınırlandırın; doğrudan erişim CDN/WAF politikasını atlamamalıdır. CDN önbellek kurallarıyla Varnish kurallarını uyumlu tasarlamak için CDN önbellekleme ve Cache-Control başlıkları rehberimizdeki önerilerden yararlanabilirsiniz.

Adım Adım Kurulum: Varnish + Nginx Reverse Proxy Örneği

Aşağıdaki adımlar Ubuntu/Debian üzerinde HTTP laboratuvar düzenini kurar; herkese açık HTTPS geçişi için TLS frontend ayrıca yapılandırılmalıdır. Mevcut çalışan Nginx uygulama ayarlarınızı koruyun. Apache 2.4 için aynı akış geçerlidir, fakat Listen, VirtualHost ve PHP işleyici sözdizimi farklıdır. Üretim geçişinden önce yapılandırma yedeğini ve geri dönüş adımlarını hazırlayın.

1) Nginx’i İç Porttan Yayın Yapacak Şekilde Ayarlama

Varsayılan kurulumda Nginx 80. portu dinler. Varnish’in bu portu devralabilmesi için Nginx’i 8080’e taşıyoruz. Port numarasını değiştirmek erişimi kendiliğinden dahili hale getirmez; backend portuna erişim yalnızca Varnish ile sınırlandırılmalıdır.

Örnek Nginx bloğu: Bu, eksiksiz bir WordPress/Laravel güvenlik yapılandırması değildir. Alan adı, public belge kökü ve kurulu PHP-FPM soketini doğrulayın; mevcut uygulamanın gizli dosya ve yükleme dizininde PHP çalıştırma engellerini koruyun. Soket adı dağıtıma ve PHP sürümüne bağlıdır.

server {
    listen 127.0.0.1:8080;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Bu tek sunucu örneğinde backend yalnızca loopback üzerinde dinler. Varnish’e ayrılacak 80. portu kullanan diğer IPv4/IPv6 vhost’larını da gözden geçirin. sudo nginx -t başarılıysa sudo systemctl reload nginx çalıştırın; ardından curl -H "Host: example.com" http://127.0.0.1:8080/ ile doğru uygulamaya ulaşıldığını kontrol edin. Başka sunucudaki backend için özel IP ve yalnızca Varnish kaynaklarına izin veren ağ kuralı gerekir.

2) Varnish Kurulumu ve Backend Tanımı

Ubuntu/Debian üzerinde yönetici yetkisiyle dağıtım paketini kurun; kullanılabilir sürüm ve destek durumu deponuza bağlıdır:

sudo apt update
sudo apt install varnish
sudo varnishd -V

/etc/varnish/default.vcl yolunu etkin servis komutundan doğrulayın. Mevcut backend default tanımını güncelleyin; ikinci bir aynı adlı backend eklemeyin. Aşağıdaki başlangıç politikası sorgu parametreli istekleri ve belirtilen özel yolları atlar; uygulamanızın diğer özel/API yollarını da ekleyin.

Basit backend tanımı:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.url ~ "^/(wp-admin|wp-login[.]php|cart|checkout|my-account)(/|[?]|$)"
        || req.url ~ "[?]") {
        return (pass);
    }
    # Yerleşik VCL, Authorization ve Cookie isteklerini pass eder.
}

sub vcl_backend_response {
    # Surrogate-Control olsa da private/no-store politikasını koru.
    if ((beresp.status != 200 && beresp.status != 301)
        || beresp.http.Cache-Control ~ "(?i)(no-cache|no-store|private)") {
        set beresp.ttl = 0s;
    }
    # Yalnızca üst sınır: kısa, sıfır veya negatif TTL yükseltilmez.
    if (bereq.url ~ "(?i)[.](png|jpe?g|webp|css|js|gif|svg)([?].*)?$") {
        if (beresp.ttl > 1h) { set beresp.ttl = 1h; }
    } else if (beresp.ttl > 120s) {
        set beresp.ttl = 120s;
    }
    # Başlangıçta bayat yanıt sunma; yalnızca belirlenmiş politikayla aç.
    set beresp.grace = 0s;
    # return(deliver) kullanma; yerleşik yanıt korumaları çalışsın.
}

TTL değerleri birer üst sınırdır: statik uzantıda en çok bir saat, diğer yanıtlarda en çok 120 saniye. Daha kısa veya sıfır/negatif origin TTL yükseltilmez; dosya uzantısı tek başına önbellekleme izni değildir. Yerleşik VCL, Authorization/Cookie isteklerini pass eder; Set-Cookie, Vary:* ve saklanmaması gereken yanıtları da korur. Buradaki ek kural, Surrogate-Control bulunsa bile Cache-Control: private/no-store/no-cache politikasını korur. Yerleşik kodun 120 saniyelik hit-for-miss kaydı, özel yanıt gövdesini 120 saniye saklamak anlamına gelmez. Başlangıç örneği grace=0s ile bayat yanıt sunumunu kapatır. Uygulama başlık vermiyorsa sürümün default_ttl değeri geçerli olabilir; önbelleğe uygunluğu uygulama tarafında açıkça belirtin.

3) Varnish’in 80. Portu Dinlemesini Sağlamak

Paket dosyasını veya multi-user.target.wants altındaki etkinleştirme sembolik bağlantısını düzenlemeyin. Önce systemctl cat varnish ve systemctl show varnish -p Type -p ExecStart -p FragmentPath -p DropInPaths ile etkin tanımı inceleyin, sonra sudo systemctl edit varnish ile yerel drop-in açın. ExecStart değişimi boş ExecStart= satırıyla önceki komutu sıfırlar; ardından bütün komut yeniden yazılır.

Koşullu drop-in örneği: Yalnızca mevcut servisiniz Type=simple ile çalışıyor, aşağıdaki tam komutun 6081 portlu karşılığını kullanıyor ve secret dosyası mevcut/uygun izinlere sahipse bu örnekte yalnızca dinleme portunu değiştirebilirsiniz. Paketinizde farklı jail, kullanıcı, PID, secret veya başka parametreler varsa bunları kendi tam komutunuzda koruyun. -F foreground çalışır; Type=forking ile bu örneği kullanmayın, Type/komut çiftini paketinizin yöntemine göre koruyun.

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -F -a :80 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,2G

Burada dikkat edilmesi gereken noktalar:

• -a :80 HTTP dinleyicisidir; yalnızca HTTP laboratuvarı içindir. TLS frontend düzeninde Varnish dinleyicisini örneğin -a 127.0.0.1:6081 ile yerelleştirin.
• -T 127.0.0.1:6082 yönetim arayüzüdür. -S kimlik doğrulama secret dosyasını belirtir; yönetim portunu internete açmayın ve kimlik doğrulamayı kapatmayın.
• -f VCL yolunu, -s malloc,2G yaklaşık 2 GiB malloc nesne deposu sınırını belirtir. Bu önceden ayrılmış RAM veya toplam süreç bellek sınırı değildir; nesne/iş parçacığı ek yükü ve Transient depolama ayrıca hesaba katılır.
• PHP-FPM, veritabanı ve işletim sistemi için kaynak bırakın; yoğun yükte RSS, depolama kullanımı ve LRU tahliyelerini ölçün.

VCL derlemesi başarılı olduktan sonra servisi yeniden başlatın. Komutu kurulumunuzdaki binary, VCL ve VMOD yollarına uyarlayın. Derleme, uygulamanın önbellek politikasını doğrulamaz:

sudo varnishd -C -f /etc/varnish/default.vcl >/dev/null &&
    sudo systemctl daemon-reload &&
    sudo systemctl restart varnish &&
    sudo systemctl status varnish --no-pager

Servis sağlıklıysa, alan adı ve ağ erişimi doğruysa HTTP isteğini Varnish karşılar. curl -H "Host: example.com" http://127.0.0.1/ ile GET yanıtını kontrol edin; Via/X-Varnish katmandan geçişi gösterir, tek başına cache hit kanıtı değildir. Başarısız geçişte kaydedilmiş servis ve web sunucusu ayarlarına birlikte dönün. HTTPS frontend’de doğru Host ve güvenilir bağlantıdan gelen şema bilgisi korunmalı, uygulama yalnızca tanımlı proxy’ye güvenmelidir; aksi halde yanlış alan adı veya yönlendirme döngüsü oluşabilir.

WordPress/WooCommerce için Varnish VCL İpuçları

VCL ile istek, yanıt ve başlıklara göre önbellek politikası tanımlanır. WordPress ve WooCommerce gibi uygulamalarda çerezler, oturumlar ve kişiselleştirilmiş yanıtlar birlikte değerlendirilmelidir.

Oturum açmış kullanıcıları Cache Dışında Bırakmak

Temel ayrım şöyledir:

• Ziyaretçi giriş yapmamışsa → yalnızca kişiye özel olmayan, ortak önbelleğe uygun HTML çıktısını cache’le; anonim sepet ve oturum içeriklerini hariç tut.
• Ziyaretçi giriş yapmışsa → kişiye özel içerik olabilir, bu yüzden pass (cache’siz) çalış.

WordPress oturum çerezleri önemlidir; ancak yalnızca wordpress_logged_in_ kontrolü yeterli değildir. Varsayılan VCL tüm Cookie isteklerini pass eder. Aşağıdaki isteğe bağlı örneği ancak /public-news yolunda adı verilen üç çerezin yanıtı değiştirmediğini uygulama testiyle doğruladıysanız kullanın. import cookie; üst düzeye bir kez eklenir; örnekteki vcl_recv önceki vcl_recv’in yerine geçer, diğer özel yol kurallarınızı koruyun.

import cookie;

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.http.Authorization
        || req.url ~ "^/(wp-admin|wp-login[.]php|cart|checkout|my-account)(/|[?]|$)"
        || req.url ~ "[?]") {
        return (pass);
    }
    # Bu çerezleri yalnızca uygulamada doğrulanmış bu genel yolda kaldır.
    if (req.url ~ "^/public-news(/|$)" && req.http.Cookie) {
        cookie.parse(req.http.Cookie);
        cookie.delete("_ga");
        cookie.delete("_gid");
        cookie.delete("_fbp");
        set req.http.Cookie = cookie.get_string();
        if (req.http.Cookie == "") {
            unset req.http.Cookie;
        }
    }
    # Kalan Cookie, yerleşik pass kuralına ulaşır.
}

cookie VMOD, adları tam eşleşmeyle siler; _ga_extra gibi başka adları silmez. Bilinmeyen, oturum, sepet ve A/B varyant çerezlerini koruyun. Kalan Cookie yerleşik pass kuralına ulaşır; erken return(hash) eklemeyin. Çerezi kaldırmak yanıtı kendiliğinden güvenli yapmaz: origin başlıkları, kullanıcıya özel fiyat/konum bilgisi ve uygulamanın diğer varyantları da kontrol edilmelidir. Varnish’i atlamak, uygulama veya CDN önbelleğini atlamak değildir.

WooCommerce Sepet, Ödeme ve Hesap Sayfaları

WooCommerce sitelerinde sepet, ödeme ve hesap yanıtlarının ortak önbelleğe alınması, kullanıcıların birbirinin sepetini görmesi gibi ciddi sorunlar doğurabilir. Aşağıdaki yollar yaygın örneklerdir; bypass kurallarını mağazanızdaki gerçek URL’lere ve yerelleştirilmiş sayfa yollarına uyarlayın. Oturum çerezlerini ve kişiselleştirilmiş dinamik/API yanıtlarını da önbellek dışında tutun:

• /cart/
• /checkout/
• /my-account/

Bu kontrol, tek vcl_recv içinde çerez temizleme veya herhangi bir erken hash kararından önce bulunmalıdır; önceki örnek zaten bu üç yolu içerir. WooCommerce’te ayarlı ve yerelleştirilmiş gerçek sayfa yollarını, alt dizin kurulumunu, ilgili API’leri ve eklenti endpoint’lerini de kapsayın:

if (req.url ~ "^/(cart|checkout|my-account)(/|[?]|$)") {
    return (pass);
}

WooCommerce tarafında veritabanı performansı ve indeksleme de en az önbellekleme kadar kritik. Bu konuda daha derin optimizasyon yapmak isterseniz, WooCommerce için MySQL/InnoDB tuning kontrol listesini anlattığımız rehbere göz atmanızı öneririz.

Cache-Control Header’ları ile Uyumlu Çalışmak

Modern uygulamalarda HTTP cache yönetimini sadece Varnish tarafında değil, aynı zamanda uygulamanın ürettiği Cache-Control başlıklarıyla birlikte düşünmek gerekir. Örneğin:

Cache-Control: public, max-age=120, stale-while-revalidate=30, stale-if-error=86400

Bu başlık, destekleyen önbellekler için 120 saniye tazelik, ardından 30 saniye stale-while-revalidate ve uygun hata koşullarında 86400 saniye stale-if-error izni ifade eder. Varnish 7.6, stale-while-revalidate değerini grace başlangıcı olarak okur; stale-if-error başlığını tek başına eklemek otomatik bir günlük hata toleransı kurmaz. Yukarıdaki başlangıç VCL’i grace’i sıfırlar. Bayat yanıt sunmayı açarken hangi genel yolların buna uygun olduğunu ve maksimum süreyi ayrıca belirleyin; özel sayfalarda kullanmayın. Arka plan yenilemesinin 5xx yanıtıyla iyi nesneyi değiştirmemesi için uygun vcl_backend_response politikasında if (beresp.status >= 500 && bereq.is_bgfetch) { return (abandon); } değerlendirilebilir; bu tek başına tüm hata koşullarını çözmez. keep, koşullu yeniden doğrulama için ek saklamadır, sınırsız bayat yanıt izni değildir. Ayrıntılar için stale-while-revalidate ve stale-if-error rehberine bakabilirsiniz.

Performans Kazançları: TTFB, RPS ve Kaynak Kullanımı

Varnish katmanının etkisini TTFB, istek kapasitesi ve kaynak kullanımı üzerinden değerlendirebilirsiniz. Aşağıdaki sayısal senaryolar varsayımsaldır; DCHost ölçümü veya performans garantisi değildir:

1) TTFB (Time To First Byte) İyileşmesi

Sayısal bir örnek için, dinamik üretilen bir WordPress sayfasının TTFB değerinin 300–800ms olduğunu varsayalım. Bu aralık tipik değer iddiası değildir; uygulama, veritabanı, ağ ve ölçüm noktasına göre değişir. Önbellek isabetinin yüksek olduğu varsayımsal karşılaştırmada:

• Varnish cache hit yanıtları için TTFB’nin 20–60ms olduğunu varsayabiliriz.
• Ziyaretçiye yakın bir CDN noktasından verilen cache hit yanıtları için 10–40ms varsayabiliriz; bu değerler beklenen sonuç değil, örnek hesabın girdileridir.

TTFB, Core Web Vitals metriklerinden biri değildir; mevcut metrikler LCP, INP ve CLS‘dir. TTFB’nin düşmesi LCP (Largest Contentful Paint) iyileşmesine katkı sağlayabilir, ancak otomatik puan veya arama sıralaması kazanımı garanti etmez. Sunucu tarafı metriklerin SEO ve kullanıcı deneyimine etkisini detaylıca anlattığımız Core Web Vitals ve hosting altyapısı rehberini de bununla birlikte okumanız faydalı olur.

2) RPS (Request Per Second) Kapasitesinin Artması

Varsayımsal bir örnek üzerinden gidelim:

• Öncesinde: Tek bir NVMe VPS üzerinde Nginx + PHP-FPM ile saniyede 150–200 istek civarında CPU %80–90’lara vuruyor, tepki süreleri uzamaya başlıyor.
• Varnish sonrası: Aynı VPS’nin yeterince yüksek bir cache hit oranıyla saniyede 800–1500 isteği karşılayabildiğini varsayalım. Örneğin %90 isabette backend’e kalan trafik yaklaşık 80–150 istek/s olur; bu hesap Varnish’in kendi yükünü ve istek maliyetlerindeki farkları ölçmenin yerini tutmaz.

Önbelleklenebilir trafiğin yoğun olduğu e-ticaret sitelerinde ve haber portallarında bu yaklaşım trafik artışlarını karşılamaya yardımcı olabilir; sepet ve ödeme gibi bypass edilen akışların kapasitesi ayrıca ölçülmelidir. Yük testlerini planlarken, Varnish öncesi ve sonrası kapasite farkını ölçmek için k6, JMeter ve Locust ile load test rehberimizde anlattığımız senaryolardan yararlanabilirsiniz.

3) CPU, I/O ve Veritabanı Yükünün Azalması

Önbellekten karşılanan isteklerin artması, uygulama katmanına ulaşan işi azaltabilir. Ancak güvenli önbellekleme için uygulamanın başlıklarında veya oturum politikasında da düzenleme gerekebilir:

• PHP-FPM’e ulaşan iş azalırsa işlem havuzlarının pm.max_children limitine dayanma ihtimali düşebilir.
• Önbellekten sunulan sayfalar için uygulama sorguları azalabilir; InnoDB buffer pool verimliliği ayrıca ölçülmelidir.
• Backend’deki log yazımı ve geçici dosya üretimi azalabilir; toplam disk I/O üzerindeki etki Varnish’in loglama ve depolama ayarlarına da bağlıdır.

Varnish kurulumu planlanırken, PHP-FPM havuz ayarlarını ve veritabanı konfigürasyonlarını da gözden geçirmek yararlıdır. Önbelleğe alınmayan istekleri karşılayan uygulama katmanının kapasitesi ayrıca değerlendirilmelidir.

Gelişmiş Konular: Mikro Önbellekleme, PURGE ve İzleme

Temel kurulumun ardından güncelleme, kısa TTL, hata davranışı ve izleme politikalarını birlikte doğrulayın.

Mikro Önbellekleme (Microcaching)

1–5 saniyelik mikro önbellekleme, tam sayfa yanıtlarına da uygulanabilen kısa TTL’li önbelleklemedir. Kısa süreli bayatlığı tolere eden, ortak önbelleğe uygun listeler, arama sonuçları ve API yanıtlarında backend yükünü azaltabilir. TTL kısa olsa bile kişisel yanıtlar, sepet, ödeme ve oturum içerikleri ortak önbelleğe alınmamalıdır.

Bu fikir Nginx FastCGI cache tarafında da yıllardır uygulanıyor; detaylarını Nginx mikro önbellekleme rehberimizde anlattık. Aynı prensibi Varnish üzerinde de kullanabilirsiniz:

Aşağıdaki parça, önceki vcl_backend_response gövdesinin sonuna eklenir; onun gizlilik ve durum kodu kontrollerinin yerine geçmez. /public-feed yalnızca uygulama tarafından ortak önbelleğe uygunluğu doğrulanmış örnek bir yoldur.

# Mevcut vcl_backend_response sonuna, yerleşik VCL çalışmadan önce ekle.
if (bereq.url ~ "^/public-feed(/|[?]|$)" && beresp.status == 200
    && beresp.ttl > 5s) {
    set beresp.ttl = 5s;
}
# Bayat yanıt sunumu açıkça tanımlanmadıkça grace=0s kalsın.

Bu kural pozitif TTL’yi en çok beş saniyeye indirir; sıfır/negatif TTL’yi veya 5xx yanıtlarını önbelleklenebilir hale getirmez. Sepet, ödeme ve kişisel API yanıtları için kısa TTL de veri sızıntısını önlemez. Aynı anda gelen genel liste isteklerinde olası kazancı gerçek trafik dağılımıyla ölçün.

PURGE / BAN: Önbelleği Uygulamadan Temizlemek

Varnish kullandığınızda, içerik güncellendiğinde (örneğin WordPress’te yazı kaydedildiğinde) ilgili sayfaların önbelleğini temizlemek için bir mekanizma kurmanız gerekir. İki yaygın yöntem:

• PURGE: Normal hash anahtarına göre eşleşen nesneyi ve Vary varyantlarını kaldırır; varsayılan anahtarda Host ve URL vardır. Doğru alan adı ve yol kullanılmalıdır.
• BAN: İfadeye uyan mevcut nesneleri geçersiz kılar; gelecekte oluşturulacak bütün yanıtlar için kalıcı yasak değildir. Liste, kategori, ana sayfa ve CDN kopyaları ayrıca ele alınmalıdır.

PURGE için yetki sınırı: Aşağıdaki loopback ACL yalnızca yetkili yerel süreçlerin yönetim isteği gönderebildiği tek sunucu düzeninde kullanılabilir. Ön tarafta yerel TLS proxy varsa dışarıdan gelen istekler de 127.0.0.1 görünebilir; bu nedenle tüm herkese açık frontend’lerde PURGE’ü Varnish’e ulaşmadan reddedin. Bu sınır sağlanamıyorsa örneği kullanmayın; ayrı doğrulanmış yönetim kanalı tasarlayın. ACL üst düzeye, PURGE dalı mevcut vcl_recv’in en başına, GET/HEAD dışı pass kontrolünden önce eklenir.

acl purge {
    "127.0.0.1";
    "::1";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return (synth(405, "Not allowed"));
        }
        return (purge);
    }
    # Mevcut yöntem, özel yol ve çerez kurallarını bu dalın arkasında koru.
}

Yetkili yerel süreç, HTTP laboratuvarında curl -X PURGE -H "Host: example.com" http://127.0.0.1/yazim/ kullanabilir; TLS düzeninde doğrudan yerel Varnish portunu belirtin. URL’nin sorgu ve sondaki eğik çizgi biçimi önbellekteki anahtarla eşleşmelidir. HTTP 200 cevabı tüm ilişkili sayfaların veya CDN kopyalarının temizlendiğini kanıtlamaz; içerik güncellemesini dışarıdan yeniden okuyarak doğrulayın. WordPress entegrasyonunun kimlik doğrulama ve kapsamını test edin.

Varnish Loglama ve İzleme

Performansını gözünüzle görmek için Varnish’in sunduğu araçlar oldukça faydalıdır:

• varnishstat → Cache hit/miss oranları, backend isteği sayıları, bellek kullanımı vb.
• varnishlog → Belirli bir isteğin baştan sona nasıl işlendiğini detaylı gösterir.
• varnishhist → Hit/miss dağılımını histogram olarak sunar.

Prometheus/Grafana gibi araçlarla isabet, miss, pass, hit-for-miss, backend hata oranı ve bellek tahliyeleri izlenebilir. Eşit süreli iki ölçüm arasındaki sayaç farklarını kullanın; süreç yeniden başladıysa dönemleri karıştırmayın. Δcache_hit / (Δcache_hit + Δcache_miss) yalnızca bu iki sayacın oranıdır, tüm HTTP trafiğinin önbellekten karşılanma oranı değildir. URL bazında karar için varnishlog ve yanıt gövdesi/başlıklarını birlikte inceleyin; özel sayfanın doğru biçimde pass edilmesini hata saymayın.

Varnish mi, Nginx FastCGI Cache mi, CDN mi? Doğru Kombinasyon

Önbellekleme dünyasında sadece Varnish yok; Nginx FastCGI cache, LiteSpeed Cache, Redis/Memcached object cache ve CDN edge cache gibi katmanlar da devrede. İş yüküne göre değerlendirilebilecek kombinasyonlar şöyledir:

• Az katmanlı yapı: Nginx FastCGI cache ve uygun tarayıcı/CDN başlıkları.
• Ayrı HTTP önbelleği: Varnish; uygulama ihtiyacına göre ayrıca Redis object cache veya CDN.
• Dağıtık yapı: Varnish origin cache ve CDN; veritabanı replikasyonu ayrı bir tutarlılık ve kapasite kararıdır. Katman sayısı tek başına daha iyi sonuç garantisi değildir.

Varnish, özellikle çoklu backend, gelişmiş VCL kuralları ve yüksek trafik altında ölçeklenebilirlik arayan projelerde yararlı bir araç olabilir; ek operasyon yükü de getirir. Ancak küçük bir WooCommerce mağazası için Nginx FastCGI cache de gayet yeterli olabilir; bu tarz kararları verirken WordPress’te tam sayfa önbellekleme çözümlerini karşılaştırdığımız yazıya da göz atmanızı öneririm.

VPS ve Dedicated Sunucuda Uygulama Planı

Varnish, kaynak ve erişim yetkileri uygunsa şu altyapı türlerinde değerlendirilebilir:

• NVMe VPS’ler üzerinde yüksek trafikli WordPress/Laravel projeleri
• Dedicated sunucularda büyük kataloglu WooCommerce, Magento mağazaları
• Colocation altyapısında kendi donanımını barındıran müşterilerin önüne gelen reverse proxy katmanı

Kurulum planında şu adımları izleyin:

• Uygulamanın genel/özel yanıtlarını, çerezlerini ve varyantlarını belirleyin.
• Staging’de anonim, oturum açmış, sepetli, sorgu parametreli ve farklı dil/para birimi isteklerini iki ayrı kullanıcıyla kontrol edin.
• PHP-FPM, veritabanı ve Varnish kapasitesini birlikte ölçün; TLS, backend erişimi ve PURGE yetkisini doğrulayın.
• Soğuk/sıcak önbellek, miss/pass ve backend kesintisini ayrı test edin; içerik güncelleme ve geri dönüş adımlarını deneyin.

Özet ve Sonraki Adımlar

Varnish Cache, Nginx veya Apache’nin önünde, ortak önbelleğe uygun yanıtlar için tekrar eden uygulama işini azaltabilir. Kazanç; önbelleklenebilir trafik payına, nesne boyutuna, tazelik ihtiyacına ve altyapıya bağlıdır. Giriş yapmamış ziyaretçinin de özel sepet veya oturum taşıyabileceğini hesaba katın.

• TTFB ve LCP etkisini aynı ağ ve yük koşullarında ölçün; Core Web Vitals veya arama sıralaması iyileşmesi garanti edilmez.
• RPS kapasitesini hata oranı ve p95/p99 gecikmeyle birlikte değerlendirin.
• Önbellek isabetindeki kazancı, pass/miss sırasında kalan PHP-FPM ve veritabanı yükünden ayrı raporlayın.

Darboğazın nedenini ölçtükten sonra ek önbellek katmanının yararını değerlendirin. DCHost üzerinde seçilecek VPS, dedicated veya colocation altyapısında kaynakları, yönetim yetkilerini ve uygulama gereksinimlerini hizmet kapsamıyla birlikte kontrol edin; tek başına Varnish eklemek kapasite veya erişilebilirlik taahhüdü oluşturmaz.

Başlangıç için bu yazıdaki kapasite testi, PHP-FPM, tam sayfa önbellekleme ve Core Web Vitals bağlantılarını birlikte kullanabilirsiniz. Yayına geçiş ölçütü yalnızca yüksek isabet oranı değildir: doğru kullanıcıya doğru içerik, beklenen güncellik ve denenmiş geri dönüş adımları da sağlanmalıdır.