Varnish Cache Nedir, Nasıl Kurulur? Adım Adım Rehber

Varnish Cache nedir?

Varnish Cache, web sunucunuzun önüne yerleşen açık kaynaklı bir HTTP ters proxy önbelleğidir. Sayfa yanıtlarını bellekte tutar ve aynı sayfayı isteyen ziyaretçilere uygulamanızı, PHP'yi ve veritabanını yormadan doğrudan sunar. Böylece sunucu yükü düşer, yanıt süresi kısalır ve trafik artışlarına dayanıklılık yükselir.

Bu yazıyı web sitesi ya da e-ticaret sahibi, yazılımcı ve kendi VPS'ini yöneten teknik okur için hazırladık. Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden anlatımı Varnish'in resmi dokümanına ve HTTP standartlarına dayandırdık. Komutları canlı sisteme uygulamadan önce kendi dağıtımınızın dokümanıyla karşılaştırmanızı öneririz.

Varnish Cache web siteniz için hangi sorunu çözer?

Dinamik bir sayfa her ziyarette PHP kodunu çalıştırır, veritabanına sorgu atar ve HTML üretir. Aynı sayfayı bin kişi isterse aynı işi bin kez yaparsınız. Varnish bu tekrarı keser. İlk isteği arka uca gönderir, yanıtı saklar ve sonraki isteklere kendi belleğinden cevap verir.

Bunun üç somut faydası var. İlki yanıt süresidir, çünkü bellekten gelen cevap uygulama katmanını beklemez. İkincisi dayanıklılıktır; yani kampanya trafiği geldiğinde arka uç aynı anda çok daha az istek görür. Üçüncüsü ölçeklenmedir, çünkü yeni sunucu almadan önce mevcut kaynağı daha verimli kullanırsınız.

Hız konusunun arama sonuçlarına etkisini ayrıca site hızı SEO'yu nasıl etkiler yazımızda anlattık. Varnish bu zincirde yalnızca sunucu yanıt süresini iyileştirir; görsel, JavaScript ve yazı tipi sorunlarını çözmez.

Varnish nasıl çalışır ve bir istek hangi yolu izler?

Ziyaretçinin isteği önce Varnish'e gelir. Varnish isteği bir anahtara çevirir; varsayılan olarak bu anahtar alan adı ile adresten oluşur. Anahtar bellekte varsa buna "hit" denir ve yanıt anında döner. Yoksa "miss" olur ve Varnish isteği arka uç sunucuya iletir.

Arka uç yanıt verince Varnish bu yanıtı süresi boyunca saklar. Süreyi genellikle arka ucun gönderdiği Cache-Control başlığı belirler. HTTP önbellekleme kurallarının standart tanımı için RFC 9111 metnine bakabilirsiniz.

1. Ziyaretçi sayfayı ister ve istek Varnish'e ulaşır.
2. Varnish önbellekte eşleşen kaydı arar.
3. Kayıt varsa yanıtı hemen döndürür (hit).
4. Kayıt yoksa isteği arka uca gönderir (miss).
5. Arka uç yanıt verir, Varnish yanıtı saklar ve ziyaretçiye iletir.

Bu akışın yönetimi VCL adlı yapılandırma dilindedir. VCL, hangi isteğin önbelleğe gireceğini, hangisinin atlanacağını ve ne kadar süre tutulacağını belirler.

Ayrıca bir ayrıntıya dikkat edin: önbellekteki yanıt, siz temizleyene ya da süresi dolana kadar aynı kalır. Dolayısıyla içerik güncellediğinizde eski sayfanın bir süre görünmesi normal bir sonuçtur ve bu davranışı ilerleyen bölümlerde yöneteceğiz.

Varnish, Redis ve OPcache arasındaki fark nedir?

Üçü de "önbellek" adını taşır, ancak farklı katmanlarda çalışır ve birbirinin yerine geçmez. Varnish tam HTTP yanıtını saklar. Redis uygulamanın ürettiği veriyi tutar. Öte yandan OPcache, PHP kodunun derlenmiş halini bellekte bekletir. Çoğu zaman üçü aynı sitede birlikte çalışır.

Redis ve Memcached ayrımını yazılımda önbellekleme yazımızda ayrıntılı işledik, bu yüzden burada tekrar etmiyoruz. Tablodaki ayrım size şunu söyler: Varnish uygulamanın dışında, en dış katmanda çalışır.

Varnish Cache ne zaman işe yarar, ne zaman yaramaz?

Varnish, çoğu ziyaretçinin aynı içeriği gördüğü sitelerde parlar. Haber siteleri, blog, kurumsal tanıtım sitesi ve ürün listeleme sayfaları tipik örneklerdir. Sayfa kişiye göre değişmiyorsa önbellek isabet oranı yükselir ve kazanç belirgin olur.

Öte yandan her ziyaretçiye özel içerik üreten sayfalarda Varnish'in kazancı düşer. Giriş yapmış kullanıcı paneli, sepet ve ödeme adımı bunun örnekleridir. Bu sayfaları atlatmayı ilerleyen bölümlerde ele alacağız.

• Uygun: Sık okunan, nadir değişen, herkese aynı görünen sayfalar.
• Sınırlı fayda: Az trafikli siteler; zaten hızlı bir sayfanın önüne ek katman koymak getiri sağlamaz.
• Uygun değil: Kişiselleştirilmiş, oturuma bağlı ve her istekte değişen içerik.
• Dikkat: Yavaş açılan ilk istek (miss) Varnish ile hızlanmaz.

Kurulumdan önce neleri hazırlamalısınız?

Varnish'i kurmadan önce mevcut yığınınızı bilmeniz gerekir. Web sunucunuz Nginx mi Apache mi, hangi portta dinliyor, HTTPS nerede sonlanıyor? Bu üç cevap, yapılandırmanın geri kalanını belirler.

• Bir test ortamı: Canlı siteye dokunmadan önce aynı yapıyı staging alanında deneyin.
• Erişim: Root veya sudo yetkili bir VPS gerekir; paylaşımlı hostingte bunu kendiniz kuramazsınız.
• Yedek: Yapılandırma dosyalarının ve sitenin güncel yedeği hazır olsun.
• Geri dönüş planı: Web sunucusunun eski port ayarını bir yere not edin.

Yedek konusunda emin değilseniz önce web sitesi yedekleme stratejisi rehberimize göz atın. Ayrıca alan adınızın hangi sunucuya baktığını DNS sorgulama aracımızla doğrulayabilirsiniz.

Varnish Cache'i nasıl kurarsınız?

Debian ve Ubuntu tabanlı sistemlerde Varnish dağıtımın paket deposundan gelir. Depodaki sürüm genellikle güncel kararlı sürümün biraz gerisinde kalabilir. Daha yeni sürüm gerekiyorsa Varnish'in resmi kurulum sayfasındaki depo yönergelerini izlersiniz.

sudo apt update
sudo apt install varnish
varnishd -V

Son komut kurulu sürümü gösterir. RHEL ailesi dağıtımlarda paket adı yine varnish olur ve dnf ile kurarsınız. Kurulumdan sonra systemd servisi hazır gelir, ancak varsayılan port ve bellek ayarını kendinize göre değiştirmeniz gerekir.

Paketin başlattığı komutu görmek için unit dosyasına bakın. Dosya içindeki ExecStart satırı; dinleme adresini (-a), VCL dosyasını (-f) ve depolama alanını (-s) içerir. Dağıtımınıza göre ayrıntılar değişebilir, bu yüzden aşağıdaki satırı örnek olarak okuyun.

sudo systemctl edit --full varnish

# ExecStart satırı için örnek (değerler örnektir):
ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m

Varnish'i Nginx veya Apache önüne nasıl yerleştirirsiniz?

Temel fikir basittir: Varnish ziyaretçiyle konuşur, Nginx veya Apache ise arka uç olur. Bunun için web sunucusunu eski portundan alıp yerel bir porta taşırsınız. Varnish de dışarıya açık portu devralır. Bu sırayı bozmadan geçiş yapmak için önce test portuyla başlamak güvenlidir.

Önce Varnish'i 6081 gibi bir portta çalıştırır, test eder ve yalnızca sonuçtan memnunsanız portları değiştirirsiniz. Bu yaklaşım, canlı trafiği riske atmadan her adımı gözlemlemenizi sağlar. Böylece sorun çıkarsa tek bir ayarı geri alarak eski düzene dönersiniz. Bu tablodaki port numaraları örnektir; sizin yığınınızda başka değerler olabilir.

Apache kullanıyorsanız Listen ve VirtualHost satırlarını 8080'e çekersiniz. Nginx kullanıyorsanız ilgili server bloğundaki listen satırını değiştirirsiniz. Ardından Varnish tarafında arka ucun adresini tanımlarsınız; bu adım VCL bölümünde.

Varnish HTTPS ile çalışır mı, TLS sonlandırma neden gerekir?

Klasik Varnish Cache geçmişte TLS konuşmuyordu, dolayısıyla HTTPS trafiğini çözmek için önüne ayrı bir bileşen koymanız gerekiyordu. Varnish projesinin güncel sayfası ve Varnish Software dokümanı yerleşik TLS desteğinden de söz ediyor. Bu nedenle kendi sürümünüzün dokümanını kontrol etmeniz şart.

Pratikte en yaygın düzen şöyledir: Nginx 443 portunda HTTPS bağlantısını karşılar, isteği Varnish'e iletir, Varnish de arka uç sunucuya gider. Hitch gibi özel bir TLS sonlandırıcı da bu işi görebilir. Varnish Software dokümanı, bu iki bileşenin PROXY protokolüyle konuşabildiğini anlatır; ayrıntı için TLS dokümanına bakın.

Sertifikanın nasıl çalıştığını bilmiyorsanız SSL sertifikası nedir yazımız iyi bir başlangıçtır. Kurulumdan sonra sertifikanızı SSL sorgulama aracıyla denetleyin.

Nginx ile TLS sonlandırmayı ve Varnish bağlantısını nasıl yaparsınız?

Aşağıdaki örnek, Nginx'in HTTPS'i karşılayıp Varnish'e ilettiği düzeni gösterir. example.com örnek bir alan adıdır ve sertifika yolları Let's Encrypt'in yaygın dizin düzenine göre yazılmıştır; kendi yollarınızı kullanın.

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:6081;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

X-Forwarded-Proto başlığı önemlidir. Yani arka uçtaki uygulama, isteğin aslında HTTPS ile geldiğini bu başlıktan okur. Başlık eksik olursa WordPress gibi uygulamalar yönlendirme döngüsüne girebilir. proxy_pass ve proxy_set_header yönergelerinin ayrıntısı için Nginx proxy modülü dokümanına bakabilirsiniz.

VCL nedir ve temel yapısı nasıl işler?

VCL, Varnish Configuration Language'in kısaltmasıdır. Bu dil, Varnish'in her isteğe nasıl davranacağını anlatan küçük bir program yazmanızı sağlar. Dosya, arka ucu tanımlayan bir backend bloğu ve istek yaşam döngüsünün noktalarına bağlanan alt yordamlardan oluşur.

• vcl_recv: İstek geldiğinde çalışır. Önbelleğe girip girmeyeceğine burada karar verirsiniz.
• vcl_backend_response: Arka uçtan yanıt gelince çalışır. Saklama süresini burada ayarlarsınız.
• vcl_deliver: Yanıt ziyaretçiye giderken çalışır. Test başlıkları eklemek için uygundur.
• vcl_hash: Önbellek anahtarının neyden oluşacağını belirler.

Varnish, sizin yazdığınız koddan sonra kendi yerleşik VCL kodunu da çalıştırır. Dokümana göre bu yerleşik kod, bir HTTP önbelleği için makul varsayılanlar sunar. Kopyasını varnishd -x builtin komutuyla görebilirsiniz; kaynak için yerleşik VCL sayfasına bakın.

İlk VCL dosyanızı nasıl yazarsınız?

Aşağıdaki dosya en küçük çalışan örnektir. Arka ucu 8080 portundaki web sunucusuna bağlar, bir test başlığı ekler ve yerleşik kuralların geri kalanını çalıştırır. Dosyayı /etc/varnish/default.vcl olarak kaydedebilirsiniz.

vcl 4.1;

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

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Yüklemeden önce söz dizimini denetleyin. Hata varsa komut sizi uyarır, bu yüzden canlı yapılandırmanız bozulmaz. Ardından yeni dosyayı çalışan Varnish'e yükleyip etkinleştirirsiniz.

varnishd -C -f /etc/varnish/default.vcl
sudo varnishadm vcl.load yeni /etc/varnish/default.vcl
sudo varnishadm vcl.use yeni

Varnish çerezler yüzünden önbelleği neden atlar?

Varnish dokümanı, yerleşik vcl_recv kodunun istekte çerez varsa önbelleğe almayı engellediğini belirtir. Gerekçe mantıklıdır: çerez çoğu zaman kişiye özel içerik demektir ve bir kişinin sayfasını başkasına göstermek ciddi bir gizlilik hatasıdır.

Sorun, sitelerin çoğunda anonim ziyaretçilere de çerez verilmesidir. Örneğin analitik, reklam ve tema çerezleri Varnish'in gözünde "kişisel" sayılır. Sonuç olarak isabet oranınız beklenenden çok düşük kalır ve Varnish'in kazancını göremezsiniz.

Çözüm, çerezleri ikiye ayırmaktır. Oturumu ve sepeti belirleyenleri korursunuz. Yalnızca tarayıcıda işe yarayan analitik çerezlerini Varnish'e gelmeden önce temizlersiniz. Dokümanda, arka ucunuza güveniyorsanız vcl_req_cookie alt yordamını boş döndürerek bu davranışı kapatabileceğiniz de yazıyor.

Üstelik yanıt tarafında da benzer bir kural var: yerleşik kod, Set-Cookie başlığı taşıyan yanıtları önbelleğe almaz. Bu nedenle eklentilerin gereksiz çerez ürettiği sayfalarda önce eklentiyi gözden geçirin.

WordPress için önbellek atlatma kuralları nasıl olmalı?

WordPress'te önbelleğe girmemesi gereken ilk grup yönetim ve giriş alanıdır. İkincisi giriş yapmış kullanıcılar ve yorum bırakmış ziyaretçilerdir. Üçüncüsü ise e-ticaret eklentisinin sepet çerezleridir. Aşağıdaki örnek bu mantığı gösterir; kendi eklentilerinizin çerez adlarını tarayıcı geliştirici araçlarından doğrulayın.

sub vcl_recv {
    if (req.url ~ "^/(wp-admin|wp-login\.php)") {
        return (pass);
    }
    if (req.http.Cookie ~ "wordpress_logged_in_|comment_author_") {
        return (pass);
    }
    unset req.http.Cookie;
}

Son satır, kalan tüm çerezleri siler. Bu yöntem yaygındır ama risklidir: temada ya da eklentide çerezle çalışan bir özellik varsa o özelliği sessizce bozarsınız. Bu nedenle canlıya almadan önce formları, aramayı ve üyelik akışlarını staging ortamında deneyin.

Hangi platformu seçtiğiniz de önbellek planını etkiler. Bu karar için WordPress mi özel kodlama mı yazımıza göz atabilirsiniz.

E-ticarette sepet ve ödeme sayfalarını nasıl korursunuz?

E-ticarette hata payı çok düşüktür. Bir müşterinin sepetini başka birine göstermek, hem güveni hem satışı yok eder. Bu nedenle sepet, ödeme ve hesap sayfaları her koşulda atlatılmalıdır. Ürün listeleri ve kategori sayfaları ise anonim ziyaretçi için güvenle önbelleğe girebilir.

sub vcl_recv {
    if (req.url ~ "^/(cart|checkout|my-account)") {
        return (pass);
    }
    if (req.http.Cookie ~ "woocommerce_items_in_cart|wp_woocommerce_session_") {
        return (pass);
    }
}

Bu örnek WooCommerce'in yaygın çerez adlarını ve İngilizce adres yollarını kullanır. Türkçe adres yapısı kuran mağazalarda yolları kendinize göre uyarlayın. Örnek bir mağazada ürün sayfaları önbellekten gelirken sepet daima canlı sunucudan gelmelidir.

Sayfa hızının satışa etkisini e-ticarette sayfa hızı satışları etkiler mi yazımızda işledik. Mağazanızın bütünsel yol haritası için e-ticaret danışmanlığı hizmetimiz de var.

Önbelleği nasıl temizlersiniz (purge)?

İçeriği güncellediğinizde eski sürümün ziyaretçilere gitmemesi için önbelleği temizlersiniz. Varnish dokümanı iki yol tanımlar. Purge, bir nesneyi ve varyantlarını önbellekten siler. Ban ise önbellekteki nesnelere uygulanan bir filtre gibi çalışır.

Yetkisiz kişilerin önbelleğinizi boşaltmaması için temizleme isteğini bir erişim listesiyle (ACL) sınırlandırmanız gerekir. Doküman da bunu özellikle vurgular. Aşağıdaki örnek, dokümandaki mantığın kısa bir uyarlamasıdır; IP adresi dokümantasyon bloğundan alınmış örnektir.

acl purge {
    "localhost";
    "203.0.113.10";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return (synth(405, "Not allowed."));
        }
        return (purge);
    }
}

Sunucunun içinden bir adresi temizlemek için tek komut yeter: curl -X PURGE http://127.0.0.1:6081/ornek-sayfa/ . WordPress kullanıyorsanız içerik güncellenince bu isteği otomatik gönderen bir eklenti seçebilirsiniz. Ayrıntılar için Varnish purge dokümanına bakın.

Varnish çalışıyor mu, isabet oranını nasıl izlersiniz?

Kurulumdan sonra önce yanıt başlıklarına bakın. Varnish yanıtlara Age ve Via gibi başlıklar ekler. Yukarıdaki X-Cache başlığını da eklediyseniz HIT veya MISS yazısını doğrudan görürsünüz. İkinci istekte HIT görmüyorsanız önbellek çalışmıyor demektir.

curl -sI https://example.com/ | grep -i -E "x-cache|age|via"

Sayısal izleme için varnishstat aracı yeterlidir. Tek seferlik çıktıda cache_hit ve cache_miss sayaçlarını karşılaştırarak isabet oranını yaklaşık hesaplarsınız. Bir isteği adım adım izlemek içinse varnishlog kullanırsınız.

varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss
varnishlog -g request -q 'ReqURL eq "/"'

Oran düşükse sebebi genellikle çerezler, Cache-Control başlıkları ya da adres sonuna eklenen izleme parametreleridir. Bu nedenle ilk bakacağınız yer, çerez ve başlık kurallarıdır.

Reklam kampanyalarında kullandığınız izleme parametreleri de önbelleği bölebilir. Örneğin her tıklamada farklı bir parametre taşıyan adres, Varnish için ayrı bir sayfadır. Böyle durumda VCL içinde bilinen izleme parametrelerini anahtardan çıkarmayı düşünebilirsiniz; ancak bunu yapmadan önce uygulamanın parametreyi sayfa içeriği için kullanmadığından emin olun.

Varnish SEO ve Core Web Vitals'ı nasıl etkiler?

Varnish doğrudan bir sıralama sinyali değildir. Ancak sunucu yanıt süresini kısalttığı için sayfanın ilk bayt süresi iyileşir ve bu da yükleme metriklerine dolaylı katkı yapar. Gerçek etkiyi ölçmeden vaat etmeyin.

Ölçüm için önce mevcut durumu kaydedin, sonra Varnish'i açıp aynı testi tekrarlayın. Google Lighthouse ile site performans testi rehberimiz bu karşılaştırma için uygundur. Metriklerin anlamı için Core Web Vitals nedir yazımıza bakın.

Önbellek yanlış yapılandırılırsa SEO'ya zarar da verebilir. Örneğin eski içeriğin günlerce kalması, yönlendirme döngüleri ya da hatalı durum kodlarının önbelleğe girmesi tarayıcı botlarını da etkiler. Aynı ilkeleri SEO danışmanlığı projelerinde teknik denetim sırasında da kontrol ederiz.

Varnish kurulumunda sık yapılan hatalar nelerdir?

Kurulumlarda tekrar eden hatalar nispeten bellidir, üstelik çoğu kolay önlenir. Çoğu hata, çerez ve başlık yönetiminden ya da portları karıştırmaktan doğar. Aşağıdaki liste, canlıya geçmeden önce kontrol edeceğiniz noktaları toplar.

• Her çerezi silmek: Oturum ve sepet çerezini de silerseniz kullanıcılar birbirinin içeriğini görebilir.
• HTTPS bilgisini iletmemek: X-Forwarded-Proto eksikse uygulama yönlendirme döngüsüne girebilir.
• Purge erişimini açık bırakmak: ACL olmadan herkes önbelleğinizi boşaltabilir.
• Bellek boyutunu bilmeden vermek: Sunucunun RAM'ini aşan bir değer sistemi yavaşlatır.
• Yalnız ana sayfayı test etmek: Sepet, giriş ve form sayfalarını da deneyin.

Bir diğer sık hata, önbelleğe alınmaması gereken hata sayfalarını uzun süre saklamaktır. Örneğin geçici bir 503 yanıtı önbelleğe girerse, sorun çözüldükten sonra da ziyaretçiler hata görmeye devam edebilir. Bu nedenle hata durum kodlarının saklama süresini kısa tutun ve test sırasında bilerek bir hata üretip davranışı gözlemleyin.

Güvenlik açısından önbelleğin yanında web uygulamasının kendisini de korumalısınız. Bu konuda OWASP Top 10 yazımız iyi bir kontrol listesi sunar. Önbellek bir güvenlik duvarı değildir.

Varnish Cache hangi HTTP başlıklarına bakarak karar verir?

Varnish Cache bir yanıtı ne kadar saklayacağını çoğunlukla arka ucun gönderdiği başlıklardan okur. Cache-Control içindeki max-age ve s-maxage değerleri ilk sırada gelir. Paylaşımlı önbellekler için s-maxage değeri ayrıca tanımlanabilir; bu kuralların standart tanımı yukarıda andığımız RFC 9111 metninde yer alır.

Arka uç süre bildirmezse Varnish, kendi varsayılan saklama süresini kullanır. Bu değer bir parametredir ve sürümünüzün dokümanında yazar, o yüzden burada rakam vermiyoruz. Ancak uygulamanızın doğru başlık göndermesi, VCL içinde süreyi elle zorlamaktan daha temiz bir yoldur.

• Cache-Control: Saklama süresini ve önbelleğe girip girmeyeceğini söyler.
• Vary: Yanıtın hangi istek başlığına göre değiştiğini belirtir; örneğin Accept-Encoding.
• Set-Cookie: Varnish'in yanıtı önbelleğe almamasına yol açabilir.
• Age: Nesnenin önbellekte ne kadar süredir durduğunu gösterir.

Vary başlığına özel dikkat edin. Yanlış bir Vary değeri, aynı sayfanın önbellekte onlarca kopyasını üretir ve böylece isabet oranını düşürür.

Varnish Cache'te statik dosyaları ve görselleri nasıl ele alırsınız?

Görsel, CSS ve JavaScript dosyaları önbelleğe en uygun içeriktir, çünkü kişiye göre değişmezler. Ancak bu dosyalar çoğu zaman çerezli isteklerle gelir ve Varnish Cache çerezi gördüğü için onları atlar. Bu yüzden statik uzantılarda çerezi temizlemek anlamlı bir kuraldır.

sub vcl_recv {
    if (req.url ~ "\.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$") {
        unset req.http.Cookie;
    }
}

Öte yandan dosya adına sürüm eki koymazsanız, güncellediğiniz dosya eski haliyle sunulabilir. Dosya adını içerik değişince değiştirmek ya da sürüm parametresi kullanmak bu sorunu önler. Görsel boyutunu küçültmek ise ayrı bir iştir; Varnish bunu yapmaz.

Varnish Cache yerine hangi alternatifler var?

Varnish tek seçenek değildir. Sitenizin yapısına, bütçenize ve yönetim becerinize göre daha basit yollar çoğu zaman yeterli olur. Aşağıdaki tablo, yaygın seçenekleri karşılaştırır; ayrıntıyı her aracın resmi dokümanında doğrulayın.

Dolayısıyla karar, yönetebileceğiniz karmaşıklıkla orantılı olmalıdır. Ekibinizde bu işi üstlenecek biri yoksa, daha basit bir çözümle ilerlemek uzun vadede daha güvenli olur.

Canlıya geçmeden önce hangi kontrol listesini izlemelisiniz?

Varnish Cache kurulumunu bir kerelik iş gibi görmeyin; geçiş adımlarını sırayla izlerseniz riskinizi düşürürsünüz. Aşağıdaki sıra, staging ortamında denediğiniz yapıyı canlıya taşırken işinize yarar.

1. Staging'de VCL dosyasını varnishd -C ile derleyip hatasız olduğunu doğrulayın.
2. Giriş, sepet, ödeme ve form akışlarını anonim ve girişli iki tarayıcıyla deneyin.
3. X-Cache başlığıyla ikinci istekte HIT gördüğünüzü onaylayın.
4. Purge isteğinin yalnızca izinli IP adresinden çalıştığını doğrulayın.
5. Geri dönüş için eski port ayarını hazır tutun.
6. İlk günlerde isabet oranını ve hata günlüklerini düzenli izleyin.

Bu listeyi bitirdiğinizde elinizde sağlam bir temel olur. Üstelik yedek, izleme ve geri dönüş planını baştan düşündüğünüz için olası bir sorunda sakin kalırsınız. Ayrıca ekibinizdeki herkes, hangi kuralın neden yazıldığını yorum satırlarından okuyabilir; dolayısıyla bakım kolaylaşır.

Varnish Cache'i ne zaman kendiniz kurmamalı, hosting sağlayıcınıza bırakmalısınız?

Dürüst olalım: Varnish her site için doğru araç değil, her ekip için de değil. Paylaşımlı hostingte kökte erişiminiz olmadığı için zaten kuramazsınız. Bu durumda sağlayıcınızın sunduğu önbellek katmanını kullanmanız daha sağlıklıdır.

• Sunucuda root erişimi ve komut satırı deneyiminiz yoksa kurulumu sağlayıcıya ya da bir sistem yöneticisine bırakın.
• Canlı bir e-ticaret sitesinde ilk denemeyi yapmayın; önce staging kurun.
• Hosting sağlayıcınız zaten bir önbellek sunuyorsa ikinci bir katman eklemeden önce onların desteğine danışın.
• Sitenizin sorunu yavaş veritabanı sorgusu ya da ağır görselse önce onu düzeltin.

Bu kararda sağlayıcı seçimi de rol oynar. Web sitesi için hosting nasıl seçilir rehberimiz, hangi paketin hangi esnekliği verdiğini anlamanıza yardım eder. Ekibimiz hosting işletmez; bu yüzden burada yalnızca resmi dokümanlara dayanan bir çerçeve sunuyoruz.

Web sitenizin teknik altyapısını ve performansını birlikte planlamak isterseniz web tasarım hizmetimiz bunu kapsar.