Nginx Mikro Önbellekleme ile PHP Uygulamalarını Uçurmak: 1–5 sn Cache, Bypass ve Purge Ne Zaman, Nasıl?

Ofiste Bir Kampanya Sabahı ve Mikro Önbelleğin Fısıldadığı Çözüm

Hiç şöyle oldu mu? Bir kampanya maili gider, sosyal medya bir anda ateş alır ve sitenin ana sayfası çığ gibi trafik altında ezilir. O sabah, kahvemi yarım bırakıp monitöre yapıştığımı hatırlıyorum. CPU tavan, PHP-FPM kuyrukta inliyor, TTFB kıpırdamıyor. Derken mikro bir dokunuş geldi aklıma: Nginx mikro önbellekleme. Aslında yıllardır bildiğimiz bir eşya gibi; çekmece kenarında bekleyen küçük bir tornavida. Bir çevirdim, her şey yerine oturdu.

Bu yazıda tam da o küçük tornavidayı konuşacağız. 1–5 saniyelik cache süresiyle dinamik PHP sayfalarını nasıl yumuşacık hızlandırabileceğimizi, hangi durumlarda bypass edeceğimizi ve gerektiğinde nasıl temiz bir purge yapacağımızı adım adım anlatacağım. Mesela şöyle düşünün: Her istek taze pişsin demiyoruz, sadece aynı anda gelen onlarca isteği birkaç saniyelik bir ara bellekte tutarak fırının kapısını gereksiz yere açmıyoruz. Aradaki fark, gerçek dünyada gözle görülür oluyor.

İşin güzel tarafı, bunu ister WordPress, ister Laravel, ister özel geliştirilmiş bir PHP uygulaması olsun, birkaç akıllı kural ve ufak dokunuşla yayına alabiliyoruz. Ben kendi yaşadıklarımla harmanlayıp, anlaşılır ve sıcak bir akışla paylaşacağım. Hazırsanız başlayalım.

Mikro Önbellekleme Nedir, Neden 1–5 Saniye?

Önbellek deyince çoğumuzun aklına dakikalar, saatler gelir. Mikro önbellekleme ise tam tersine, 1–5 saniye gibi minicik bir zaman diliminde çalışır. Peki bu kadar kısa süre ne işimize yarar? Trafiğin dalgalandığı anlarda, ilk isteği uygulamaya gönderir, yanıtı birkaç saniyeliğine Nginx’te saklarız. Aynı içerik için peş peşe gelen istekler o kısa süre içinde doğrudan Nginx’ten çıkar. Uygulama katmanı derin bir nefes alır.

Bu yaklaşım, kişiselleştirme içermeyen ya da hafif kişiselleştirilmiş sayfalarda anlık taşmaları yumuşatır. Ana sayfa, kategori listeleri, popüler içerik sayfaları ya da yoğun yorum alan blog yazıları gibi kalabalık noktalar için birebir. Süre kısa olduğu için mutlak tutarlılık talebi olan sayfalarda bile risk minimal kalır. Yanlış bir içerik görme ihtimali, insanın göz kırpması kadar bir zamana sığar, çoğu kullanıcı fark bile etmez.

Dezavantajı yok mu? Var elbette. Bazı sayfalar anlık kişiselleştirme taşır; örneğin kullanıcıya özel selamlama, sepet özeti, CSRF token gibi öğeler. Bu alanlarda mikro önbellek ya devre dışı bırakılmalı ya da bu kişisel parçalar ayrı düşünülmeli. Ama paniğe gerek yok, bypass dediğimiz şey tam da bunun için var.

PHP ile Nginx’te Mikro Önbellek: FastCGI mi, Proxy mi?

PHP-FPM kullanıyorsanız yolumuz çoğunlukla fastcgi_cache üzerinden geçer. Mikro önbellekleme burada gerçek anlamda parlıyor. Çalışma prensibi basit: Nginx, upstream olarak PHP-FPM’ye gider, dönen yanıtı dosya tabanlı bir cache’te tutar ve kısa bir süreliğine tekrar eden isteklere aynı yanıtı sunar.

İlk kurulumda genelde yaptıklarım çok benzer olur. Bir cache alanı tanımlarım, anahtar seçimimi netleştiririm, sonra bypass kurallarıyla içimi rahatlatırım. Kod gibi görünse de, aslında bu, mutfaktaki ölçülü tarifin aynısıdır.

# nginx.conf ya da http bloğu
fastcgi_cache_path /var/cache/nginx/micro levels=1:2 keys_zone=microcache:50m inactive=10s use_temp_path=off;

map $http_cookie $skip_cache {
    default 0;
    ~*(wordpress_logged_in|comment_author|laravel_session) 1; # girişli/kisisel oturumlar
}

map $request_method $skip_cache_method {
    default 0;
    ~*(POST|PUT|PATCH|DELETE) 1; # yazan istekler cache'lenmez
}

map $arg_nocache $skip_cache_arg {
    default 0;
    1 1; # ?nocache=1 gelirse bypass
}

map $http_cache_control $skip_cache_cc {
    default 0;
    ~*no-cache 1;
}

Sunucu bloğunda ise tipik bir PHP konfigürasyonu şöyle şekillenir. Burada süreleri özellikle kısacık tutuyorum.

server {
    listen 80;
    server_name example.com;

    root /var/www/html;

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        set $skip $skip_cache;
        if ($skip_cache_method) { set $skip 1; }
        if ($skip_cache_arg)    { set $skip 1; }
        if ($skip_cache_cc)     { set $skip 1; }

        fastcgi_cache microcache;
        fastcgi_cache_key $scheme$request_method$host$request_uri;
        fastcgi_cache_valid 200 302 1s;
        fastcgi_cache_valid 404 1s;
        fastcgi_cache_bypass $skip;
        fastcgi_no_cache    $skip;

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

        add_header X-Cache $upstream_cache_status always;
    }
}

Burada fastcgi_cache_lock küçük ama kritik bir detay. Aynı anda gelen onlarca istek birbirini ezmesin diye, ilk isteğin upstream’den yanıtını beklerken diğerleri kilitte oyalanır ve o yanıtı paylaşır. Cache stampede dediğimiz dalga böylece sönümlenir. Ayrıca stale kullanımını açınca, upstream anlık hata verdiğinde bile yakın zamanda alınan yanıtı geçici olarak sunma şansı doğar. Bu, kampanya sabahlarının dayanağıdır.

Detaylarına meraklı olanlar için belgenin kendisi bir hazine: nginx fastcgi_cache yönergeleri ve fastcgi_cache_path yapılandırması kılavuz gibi yanınızda dursun.

Cache Key, Varyasyonlar ve Minicik Ama Etkili Bir TTL

Cache anahtarı, mikro önbelleğin kalp atışı. Anahtarı ne kadar doğru kurarsanız, o kadar az sürpriz yaşarsınız. Ben genellikle $scheme$request_method$host$request_uri ile başlarım. Eğer sitenizde dil parametresi, cihaz türü ya da farklı içerik türlerini etkileyen query parametreleri varsa, anahtara bunları da katmayı düşünün. Mesela mobil ve masaüstü için aynı HTML çıkmıyorsa, cihaz ayırıcı bir sinyal kullanmak iyi gelir.

Akla şu soru gelir: 1–5 saniye arası hangisini seçmeli? Ben bunun cevabını sayfa tipine bırakıyorum. Trafiğin dalgalandığı ana sayfada 2–3 saniye tatlı bir yer. Haber gibi anlık güncellenen akışlarda 1 saniye daha güvenli hissettirir. Kategori ya da liste sayfalarında 5 saniye bile gayet nazik davranır. Önemli olan, bu sürelerin göz açıp kapayıncaya kadar geçtiğini ve kullanıcının çoğu zaman fark etmeyeceğini unutmamak.

Bir diğer incelik, yanıtın varyasyonunu belirleyen başlıklardır. Accept-Encoding ve benzeri başlıklar genelde Nginx tarafından otomatik yönetilir. Ancak dil varyasyonu taşıyorsanız Accept-Language ya da URL tabanlı dil seçicileri net olmalı. Cache key’in kararsız kalması, mikro önbelleğin gücünü kırar.

Bypass Stratejileri: Kimin Yolunu Açacağız?

Mikro önbellekte asıl ustalık, bypass kararında gizlidir. Herkesi aynı mikserde çevirmiyoruz. Giriş yapmış kullanıcı, sepetinde ürün taşıyan ziyaretçi, form gönderen konuk… Bunların yanıtı taze gelmeli. Bunun için ben üç kapı kuralını severim: cookie’ler, istek türü ve açık komut.

Cookie tarafında WordPress için wordpress_logged_in, yorum bırakanlar için comment_author, Laravel için laravel_session cankurtaran gibidir. Bu işaretleri görünce cache’i nazikçe pas geçeriz. Yazma yapan istekleri (POST, PUT, DELETE) zaten hiç önbelleğe almayız. Son olarak, bazı durumlarda ?nocache=1 gibi bir parametre ile geliştirici veya operasyon tarafına elle bypass imkanı vermek çok rahatlatıcı olur.

WordPress dünyasında giriş sayfaları başlı başına bir alem. Buraları ayrı korumak akıllıca. Ben çoğu projede wp-login ve XML-RPC için hız sınırlama ve güvenlik önlemlerini mikro önbellekle beraber düşünürüm. Önbelleğe girmeyecekleri kesin, ama baktığınızda performans hikayesini tek başına bu alanlar bozmasın.

Kimi uygulamalarda yanıtlar masum görünür ama Set-Cookie başlıkları sessizce çalışır. Bu tür yanıtları cache’lemek çoğu kez tatsız sürprizler doğurur. Ben genelde bu tür başlıklar geldiğinde no cache demeyi yeğliyorum. Yani temel prensip şu: kişiye özgü bir şey görürsen, bypass et; herkese aynı gösterilecek bir şeyse, mikro bir süreliğine sakla.

Purge Stratejileri: Ne Zaman Temizlik Gerekir?

Mikro önbellekte TTL o kadar kısa ki, çoğu zaman ayrıca purge etmeye gerek kalmaz. Bir-iki saniye sonra zaten tazelenecek bir yanıtı silmek, çoğu senaryoda enerjinizi boşa harcar. Yine de, bazı akışlar var ki, o saniyeyi bile beklemek istemezsiniz. Örneğin manşete giren bir haber, landing sayfasında son dakika bir değişiklik, ya da stok durumu… İşte buralarda iki yol var.

İlki, konfigürasyona küçük bir purger eklemektir. Açık kaynak Nginx’te yerleşik bir purge endpoint’i yok; bu yüzden üçüncü parti ngx_cache_purge modülü yıllardır bir omuz verir. Yetkili IP’lere açık bir “/purge” konumu tanımlayıp, belli bir URL’ye ait cache’i doğrudan temizleyebilirsiniz. En kritik not: Bu kapıyı sadece güvendiğiniz kaynaklara açın ve kayıtları tutun.

İkinci yol ise basit ve etkili bir hile: cache key versiyonlamak. Uygulama bir içerik güncellendiğinde, key’e görünmez bir işaret ekleyebilirsiniz. Mesela ?v=timestamp gibi ufak bir değişken, mikro önbelleğin aynı anda yeni versiyonu üretmesini sağlar. Eski versiyon birkaç saniye içinde zaten düşer. Kod tarafında pratik ve riskten uzak bir yaklaşım.

Dosya sistemi üzerinden doğrudan cache silmek de mümkün ama ben genelde buna temkinli yaklaşırım. Hash’lenmiş dizin yapısında yanlış bir dosyayı silmek kolaydır ve cache yöneticisi bir süre ek iş yükü altında kalabilir. Sistem karmaşıklaştıkça, purge konusunu operasyon aracı haline getirmek ve otomatikleştirmek daha sağlıklı olur.

WordPress, Laravel ve Özel PHP Uygulamalarında Püf Noktaları

WordPress’te mikro önbellek, özellikle ana sayfa, kategori arşivleri, yazar sayfaları ve yazı sayfalarında harika çalışır. Girişli kullanıcı, yönetim paneli, yorum gönderimi ve önizleme gibi alanlar doğal bypass’tır. İyi kurulmuş bir katman, Redis gibi bir nesne önbelleği ile birleşince, veritabanı yükünü de nezaketle hafifletir. Ben ikisini kardeş gibi görürüm: biri sayfayı hızlı çıkarır, diğeri veriyi yakından getirir.

Laravel tarafında rota bazlı düşünmek çok iş görür. Özellikle API ve HTML dağıtan endpoint’lerde, read heavy olanlar mikro önbelleğin tatlı müşterisidir. laravel_session cookie’sini gördüğünüz yerlerde bypass, kullanıcıya özel alanlarda bypass, statik HTML gibi davranan rotalarda mikro TTL… Hepsi bir anlam zinciri kurar. CSRF token taşıyan formlar için yanıtı cache’lememek çoğu zaman en güvenlisidir.

Özel yazılımlarda iş daha keyifli. Kendi işaretlerinizi koyar, “şu yanıtı herkese aynı veriyorum” dediğiniz alanları 1–3 saniye saklar, hassas alanları akıllıca pas geçersiniz. Kullandığınız mimari Docker ise, uygulama ve Nginx’in birlikte yaşadığı düzen izleme ve bakımda büyük kolaylık sağlar. Değişiklikleri sürümlendirir, sunduğunuz her servis için doğru log’ları bir araya toplarsınız.

Gözlemlemek, Ölçmek, Sakin Kalmak

Önbellek çalışıyor mu, nerede çakılıyor, kaçırdığımız köşe var mı? Bu soruların cevabını log ve başlıklar veriyor. Ben genellikle Nginx’te X-Cache başlığıyla MISS, HIT, BYPASS görmek isterim. Ancak bunu illa kullanıcıya göstermeye de gerek yok; log’lara yazmak yeterli. Özellikle yoğun anda kaç MISS geldiğini görmek, TTL ayarının doğru olup olmadığını fısıldar.

log_format micro '$remote_addr - $request [$time_local] '
                  '"$request" $status $body_bytes_sent '
                  '"$http_referer" "$http_user_agent" '
                  'cache:$upstream_cache_status';

access_log /var/log/nginx/access.log micro;

Bu log formatıyla HIT ve MISS dağılımını güzelce izleyebilir, gerekirse TTL’i bir tık artırıp azaltabilirsiniz. Ayrıca, upstream tarafında PHP-FPM kuyruğunu ve işlemci kullanımını takip etmek kıymetli. Mikro önbellek doğru yerde çalıştığında, bu grafiklerde huzurlu bir düzleşme görürsünüz. Bazen huzur, grafikteki o düz çizgidir.

CDN kullanıyorsanız, uç katmandaki cache ile origin’deki mikro önbelleği barıştırmak gerekir. Ben buna “katmanlar arası nezaket” diyorum. CDN kendi TTL’iyle çalışır, origin’de mikro TTL ayrı. İkisi birden olduğunda, kampanya anlarında daha da güçlü bir kalkanınız olur. İlgili bir konuda, CDN ve akıllı cache-key ile içerik dağıtımını uzun uzun konuşmuştuk; aynı mantık burada da iş görüyor.

Kenarlarda Kalanlar: Nonce, CSRF, ETag ve Set-Cookie

Gerçek hayat, belki de en çok kenar durumlarında karşımıza çıkar. WordPress nonce değerleri, Laravel’in CSRF token’ları, sepet özetleri… Bu tür öğeler sayfaya gömülüyse, mikro önbellek kısa da olsa tatsız bir sürpriz olabilir. En güvenli yaklaşım, bu alanları bypass etmektir. Kimi zaman bu öğeleri AJAX ile sonradan çekmek ve sayfayı genel olarak cache’lemek harika bir denge kurar.

Set-Cookie başlığını görünce refleks olarak cache’i kapatmak çoğu projede hayat kurtarır. ETag ve Last-Modified gibi başlıklar ise daha çok tarayıcı tarafında işe yarar; burada asıl iş Nginx’in dosya tabanlı mikro önbelleğinde döner. Yine de koşullu istek mantığını bozmayacak şekilde başlıklarınızın temiz olduğundan emin olmak güzel bir alışkanlıktır.

Ben ayrıca şuna bakarım: Sayfada kişisel bir öğe varsa ama sayfanın %95’i herkese aynıysa, o %95’i mikro önbelleğe alıp kalanını sonradan doldurmak, TTFB’yi ciddi biçimde yumuşatır. Bu, özellikle yoğun haber akışı olan sitelerde tatlı bir reçetedir.

Adım Adım Bir Kurgu: Mikro Önbellekli WordPress

Birlikte küçük bir kurgu yapalım. WordPress site, Nginx ve PHP-FPM ile çalışıyor. Ana sayfa ve yazı sayfaları trafik yiyor. Hedefimiz TTFB’yi sakinleştirmek, PHP’ye nefes aldırmak. İlk iş, microcache zone’u açıyoruz. Sonra bypass’ı netleştiriyoruz: girişli kullanıcı, yorum yazarı, admin ve POST istekleri asla cache’e girmeyecek.

fastcgi_cache_path /var/cache/nginx/micro levels=1:2 keys_zone=microcache:100m inactive=10s;

map $http_cookie $skip_cache {
    default 0;
    ~*(wordpress_logged_in|comment_author|wp-postpass) 1;
}

server {
    listen 80;
    server_name example.com;

    location /wp-admin/ { set $skip 1; try_files $uri $uri/ /index.php?$args; }
    location ~* /wp-login.php { set $skip 1; try_files $uri =404; }

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

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        set $skip $skip_cache;
        if ($request_method != GET) { set $skip 1; }

        fastcgi_cache microcache;
        fastcgi_cache_key $scheme$request_method$host$request_uri;
        fastcgi_cache_valid 200 302 2s;
        fastcgi_cache_valid 404 1s;
        fastcgi_cache_bypass $skip;
        fastcgi_no_cache    $skip;

        fastcgi_cache_lock on;
        fastcgi_cache_lock_timeout 5s;
        fastcgi_cache_use_stale updating error timeout;

        add_header X-Cache $upstream_cache_status always;
    }
}

Burada ana sayfa ve yazı sayfaları tipik olarak 2 saniye cache’e girer. Yorum gönderilince, zaten POST olduğu için bypass olur. Giriş yapan kullanıcıyı cookie üzerinden atlatırız. Yönetim paneli zaten farklı bir dünya, oraya hiç yaklaşmayız. Bu yapıyı, Redis nesne önbelleğiyle desteklemek isterseniz, yukarıda paylaştığım WordPress + Redis notları performans katmanlarını tamamlar.

Bir not daha: Eğer medyayı ve görselleri CDN’e itiyor, format dönüşümleri yapıyorsanız, WebP/AVIF sunum stratejileri ile cache anahtarını, kullanıcıya sunulan içeriğe uygun şekilde akıllandırın. Böylece Nginx’teki mikro cache ile CDN cache’i birbiriyle çelişmez, aksine omuz omuza yürür.

Cache Purge İçin Pratik Yaklaşımlar

“Peki ya manşeti şimdi güncelledik, o iki saniyeyi bile beklemek istemiyorsak?” İşte burada iki yaklaşım tekrar sahneye çıkar. Birincisi, eğer ekip ve altyapı olgun ise purge endpoint’ini kısıtlı IP’lere açıp, içerik güncellenince ilgili URL’yi vurarak temizlik yapmak. Bu yöntemi orkestrasyon araçlarına bağlayıp otomatikleştirmek güzel olur.

İkincisi, uygulama tarafında küçük bir cache-buster eklemek. Örneğin tema tarafında ana menü veya manşet alanı güncellendiğinde, ana sayfa linklerine ?v=son_degisiklik_zamani benzeri bir değişken eklersiniz. Böylece yeni içerik, eski cache ile yarışmadan hemen sunulur. Eski cache birkaç saniyede kendiliğinden düşer. Bu strateji, tek bir satır bile Nginx konfigürasyonu değiştirmeden, hızlıca devreye alınır.

Gerçek Zamanlı Trafik Dalgaları ve Sakin Bir Nginx

Kampanya sabahına dönelim. Mikro önbellek çalışırken görünen manzara şuna benziyor: İlk dalgada bir MISS, hemen arkasından HIT’ler yağmaya başlıyor. PHP-FPM kuyrukları kısalıyor, CPU nefes alıyor. TTFB 700 ms’den 120–150 ms bandına iniyor ve orada tatlı tatlı salınıyor. Sitenin genel hissiyatı “hızlı” oluyor, çünkü ilk boyama ve etkileşim için bekleme süresi düşüyor.

Yük testlerinde de benzer bir dinginlik görürsünüz. Bu dinginlik, 1–5 saniye gibi minicik bir aralığın armağanı. Aslında hiçbir şeyi kökten değiştirmiyorsunuz, sadece aynı saniyede gelen onlarca isteğin hepsini uygulamanın sırtına yıkmıyorsunuz. Mikro önbellek, tam da bu yüzden seviliyor.

CDN ile El Sıkışmak: Kim Neyi, Ne Kadar Zaman Tutar?

CDN’i origin önüne koyduğunuzda iki katmanlı bir hikaye başlar. CDN, kenar noktalarında içerikleri tutar ve kullanıcıya yakın sunar. Origin’deki Nginx ise kendi mikro önbelleğiyle anlık dalgaları yumuşatır. Bu ikili, doğru ayarlandığında büyüleyici bir uyum yakalar. CDN’de daha uzun TTL’ler, origin’de 1–5 saniyelik mikro TTL… Birlikte kusursuz bir akış kurarlar.

Buradaki kilit, cache-key uyumudur. Kullanıcıya gönderdiğiniz varyasyonlar (görsel formatı, sıkıştırma seviyesi, dil veya tema modu) CDN ve origin arasında çelişmemeli. Daha derin bir içerik dağıtım senaryosu kurgulamak isterseniz, origin shield ve akıllı cache-key tasarımı üzerine notlar karar vermeyi kolaylaştırır.

Sorun Giderme: Neyi Görünce Nereden Başlamalı?

En yaygın sorun şu olur: “Cache’e girmiyor.” Yanıt başlıklarını ve cookie’leri kontrol edin. Set-Cookie görüyorsanız, Nginx muhtemelen haklı olarak cache’i pas geçiyordur. İstek türü GET değilse zaten bypass’tır. Bir de X-Cache başlığını açtıysanız, MISS ve BYPASS ayrımını net görürsünüz. Buradan ipucunu yakalamak çok kolay.

“Cache yanlış içerik veriyor” hissi uyandığında ise ilk bakacağınız yer cache key. URL, dil, cihaz ya da önemli bir query parametresi eksik kalmış olabilir. Bir süreliğine X-Cache ile beraber, sayfanın hangi varyasyona ait olduğunu belirten küçük bir debug başlığı eklemek, sorun çözmeyi hızlandırır.

“Yük anında upstream eziliyor” anlarında ise fastcgi_cache_lock ve use_stale kombinasyonunu tekrar gözden geçirin. Lock süresi kısa kalmış olabilir ya da TTL çok küçük kalmıştır. Bir saniyeden iki saniyeye çıkmak bile dünyaları değiştirebilir.

Ek Notlar ve Güzel Küçük Dokunuşlar

Uygulamanın başlıklarıyla Nginx’in konuşmasını seviyorum. Bazı projelerde, yanıtı açıkça “bunu cache’leme” diye işaretlemek için uygulama tarafında küçük bir header yazdırıyoruz. Nginx’te map $http_cache_control $skip_cache_cc gibi kurallarla bunu yakalıyoruz. Yani uygulamanın sesi varsa, Nginx dinliyor. Bu da ekipler arası uyumu büyütüyor.

Log’ları merkezi bir yerde toplamak, alarmları basit kurallarla ayarlamak ve anomalileri hızlı görmek ayrı bir huzur. İsterseniz Loki + Promtail ile merkezi loglama notlarına göz atın; mikro önbelleğin gerçek faydasını grafiklerle izlemek çok motive edici oluyor.

Ve tabii, büyük versiyon yükseltmelerinde mikro önbelleği yeniden gözden geçirmek güzel bir alışkanlık. PHP tarafında ufak bir ayar değişikliği, Nginx’te küçük bir versiyon farkı, bütün akışı etkileyebilir. Benim için, PHP yükseltmesi sırasında yaşadığım küçük aydınlanmalar hep bu tür detaylarda saklıydı.

Kapanış: Küçük Bir Tornavida, Büyük Bir Ferahlık

Başta anlattığım kampanya sabahı, mikro önbellek bir anda ofisin kahramanı olmuştu. O gün bir şeyi net anladım: Her zaman büyük eksen kaymalarına gerek yok. Bazen 1–5 saniye gibi küçücük bir süre, koskoca bir çatıyı ayakta tutmaya yetiyor. Nginx mikro önbellekleme bu yüzden sevilesi. Basit, öngörülebilir, yumuşak.

Özetle, herkese aynı sunulan sayfaları kısacık bir süre saklayın, kişisel alanları bypass edin, gerektiğinde nazikçe purge edin. X-Cache’le, log’la, küçük alarmlarla akışı izleyin. CDN varsa el sıkıştırın. Vakit buldukça konfigürasyonu sadeleştirin; sade kalan ayarlar hata yapmaz. Umarım bu yazı, aklınızdaki taşları yerine oturtur ve ilk denemenizde yüzünüzü güldürür. Takıldığınız bir yerde “Şu sayfayı bypass mı etsek, 1 yerine 3 saniye mi versek?” diye düşünüyorsanız, doğru yoldasınız. Bir dahaki yazıda görüşmek üzere, hız sizinle olsun.