PHP Session ve Cache Depolamasını Doğru Seçmek: Dosya, Redis ve Memcached’in WordPress ve Laravel Performansına Etkisi

PHP Session ve Cache Depolamasını Neden Ciddiye Almalısınız?

WordPress ya da Laravel ile geliştirdiğiniz bir projede performans konuşulurken genelde ilk akla gelen PHP-FPM ayarları, MySQL tuning’i, CDN ve HTTP/2/3 oluyor. Ancak pratikte gördüğümüz bir gerçek var: session ve cache depolamasının türü, özellikle yüksek trafikli sitelerde TTFB’den (Time To First Byte) son kullanıcı deneyimine kadar her şeyi belirgin şekilde etkiliyor. Aynı kod tabanını, aynı CPU ve RAM kaynaklarında; sadece session ve cache depolamasını değiştirerek saniyelerle ifade edilen kazanımlar elde edebiliyoruz.

DCHost tarafında onlarca WordPress ve Laravel projesini taşırken en sık karşılaştığımız senaryo şu: Varsayılan olarak dosya tabanlı session kullanılıyor, cache ise ya veritabanında tutuluyor ya da hiç yok. Ziyaretçi ve sipariş sayısı arttığında önce admin paneli ağırlaşıyor, ardından sepet ve checkout adımları hissedilir şekilde yavaşlıyor, son aşamada da PHP süreçleri CPU’ya yüklenip tüm siteyi sürüklüyor. Oysa doğru bir “session + cache” mimarisi ile aynı altyapıda çok daha rahat nefes aldırmak mümkün.

Bu yazıda, PHP session ve cache depolaması için üç ana seçeneği; dosya sistemi, Redis ve Memcached ekseninde ele alacağız. WordPress ve Laravel özelinde hangi senaryoda hangi sürücünün mantıklı olduğuna, gerçekçi örneklerle ve sahada kullandığımız ayarlarla değineceğiz. Yazının sonunda, uygulamanız için adım adım bir yol haritası ve DCHost altyapısında bunları nasıl hayata geçirebileceğinizin özetini bulacaksınız.

Önce Temeller: PHP’de Session ve Cache Tam Olarak Nedir?

Karar vermeden önce iki kavramı netleştirmek gerekiyor: session ve cache. İkisi de bellek veya disk üzerinde veri tutuyor gibi görünse de amaçları ve kullanım biçimleri farklıdır.

PHP Session nedir?

Session, ziyaretçi ile sunucu arasında durumsal bir ilişki kurmak için kullanılır. Örneğin:

• WordPress’te bazı üyelik ve sepet eklentilerinin login durumunu saklaması,
• Laravel’de kimliği doğrulanmış kullanıcının ID’si, rolü, yetkileri,
• CSRF token’ları ve çok adımlı formlarda geçici bilgiler.

Session verisi genellikle kullanıcıya özel ve kısa ömürlüdür. Session ID bir çerez (cookie) ile tarayıcıya verilir, sunucu o ID’ye karşılık gelen veriyi session depolamasında saklar.

Cache nedir?

Cache ise sisteme binen tekrar eden yükü azaltmak için kullanılır. Örneğin:

• WordPress’te menü, site ayarları ve sık kullanılan sorguların nesne önbelleği (object cache),
• WooCommerce ürün sayfalarındaki sorgu sonuçları, sepet özeti,
• Laravel’de pahalı sorguların, API cevaplarının veya hesaplamaların önbelleğe alınması.

Cache, session’dan farklı olarak genelde kullanıcıya özel olmak zorunda değildir ve isteğe bağlıdır. Varlığı performans kazandırır, yokluğu işlevi bozmaz (doğru tasarlandıysa).

WordPress ve Laravel’de session/cache kullanım alışkanlıkları

Pratikte tablo şu şekilde:

• WordPress: Çekirdek çok yoğun session kullanmaz; fakat üyelik, sepet, üyelik alanı eklentileri kullanabilir. Asıl kazanç object cache ve tam sayfa önbellek tarafındadır.
• Laravel: Framework düzeyinde hem session hem de cache oldukça aktif kullanılır. Auth sistemi, rate limiting, queue’lar, job’lar ve config cache gibi birçok bileşen devreye girer.

Bu nedenle aynı depolama seçimi hem WordPress hem Laravel için her zaman ideal olmayabilir. Birazdan her iki dünya için ayrı ayrı öneriler yapacağız.

Dosya Tabanlı Session ve Cache: Varsayılan, Basit ama Sınırlı

PHP’yi kurup hiçbir ayar değiştirmezseniz, session’lar büyük ihtimalle dosya sistemi üzerinde tutulur. php.ini içinde klasik ayar şöyle görünür:

session.save_handler = files
session.save_path = "/var/lib/php/sessions"

Dosya tabanlı session’ın artıları

• Kurulum gerektirmez: Ek servis yok, ek bağımlılık yok.
• Küçük siteler için yeterli: Az trafikli kurumsal sitelerde genelde sorun çıkarmaz.
• Hata ayıklaması görece kolay: İlgili dizinde session dosyalarını görebilirsiniz.

Dosya tabanlı session’ın eksileri

• Disk IO bağımlılığı: Her istek, özellikle kilit (lock) mekanizması nedeniyle diske dokunur. paylaşımlı hosting veya yoğun VPS’lerde IO wait artar.
• Yüksek eşzamanlılıkta kilitlenme: Aynı kullanıcı kısa aralıklarla çok sayıda istek yaptığında (özellikle AJAX yoğun sayfalarda), session kilitleri yüzünden istekler birbirini bekler.
• Multi-node mimarilerde sorun: Birden çok PHP sunucunuz varsa, hepsinin aynı session.save_path’i paylaşması gerekir (NFS vb.). Bu da ekstra karmaşıklık ve gecikme getirir.

Dosya tabanlı cache neden nadir kullanılıyor?

Çoğu modern projede cache için dosya sistemi tercih edilmiyor. Sebepler:

• Diskteki rastgele okuma/yazma performansı; bellek tabanlı sistemlere göre çok geride,
• Dosya sayısı arttıkça dizin yönetimi ve cleanup zorlaşıyor,
• Cache’i birkaç milisaniye içinde getirip atmak istediğiniz senaryolarda disk doğal bir dar boğaz.

Özetle; dosya tabanlı session, küçük projeler için “idare eder”, ama yoğun trafik ve ölçeklenebilirlik gereken dünyada Redis veya Memcached kadar esnek değil.

Redis ile Session ve Cache Depolama: Bellek Hızı, Zengin Özellik Seti

Redis, veriyi RAM’de tutan, gerektiğinde diske de yazabilen bir key–value veri yapısı sunucusudur. Sadece session ve cache için kullanılmak zorunda değildir; ama WordPress ve Laravel ekosisteminde bu iki kullanım alanında son derece popülerdir.

Redis’in hosting performansına etkisini ayrıntılı anlattığımız Redis cache’in hosting performansını artırdığı senaryoları derlediğimiz rehbere mutlaka göz atmanızı öneririz.

Redis’in öne çıkan avantajları

• Çok düşük gecikme (latency): Veri RAM’de tutulduğu için milisaniyeler seviyesinde cevap verir.
• Gelişmiş veri yapıları: Sadece string değil; list, set, sorted set, hash, bitmap vb. veri yapıları sağlar. Laravel tarafında queue ve rate limiting gibi alanlarda da sık kullanılır.
• TTL ve eviction stratejileri: Her key’e ayrı TTL atayabilir, bellek dolunca hangi anahtarların atılacağını politika ile belirleyebilirsiniz.
• Persist edilebilir: AOF veya RDB snapshot ile RAM’deki veriyi diske yazarak belirli bir dayanıklılık sağlayabilirsiniz.

WordPress’te Redis kullanımı

WordPress ekosisteminde Redis genellikle nesne önbelleği (object cache) için devreye alınır. Çekirdek ve eklentiler, veritabanına her ihtiyaç duyduklarında önce object cache’e bakar; Redis bu katmanda araya girer.

WordPress tarafında pratik kurulum ve ayar adımlarını adım adım anlattığımız WordPress’te Redis/Memcached object cache kurulumu rehberinde hem Redis hem de Memcached için örnek yapılandırmalar bulabilirsiniz.

Özellikle WooCommerce gibi dinamik sorgu yoğun sitelerde Redis, veritabanı yükünü ciddi şekilde azaltır. Bu sayede aynı VPS veya dedicated sunucu üzerinde daha fazla eşzamanlı oturuma rahatlıkla yanıt verebilirsiniz.

Laravel’de Redis kullanımı

Laravel, Redis ile doğrudan dost diyebileceğimiz bir framework. Sadece cache ve session için değil; queue, broadcasting, rate limiting gibi birçok bileşende Redis ilk akla gelen tercihlerden.

Temel .env ayarları şu şekilde olabilir:

SESSION_DRIVER=redis
CACHE_DRIVER=redis
QUEUE_CONNECTION=redis

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
REDIS_CACHE_DB=1
REDIS_SESSION_DB=2
REDIS_QUEUE_DB=3

Burada dikkat edilmesi gereken nokta, cache, session ve queue için farklı Redis veritabanları (DB index) kullanmak. Bu hem yönetilebilirliği artırır hem de ileride sadece belirli bir veritabanını temizlemek istediğinizde işinizi kolaylaştırır.

Laravel prod ortamında Redis’in nasıl konumlandırılması gerektiğini; PHP-FPM, OPcache ve Horizon ile birlikte ele aldığımız Laravel prod ortam optimizasyonu rehberimizde daha derin teknik detaylarla bulabilirsiniz.

Redis’in dezavantajları

• Ek servis yönetimi: Redis bir arka plan servisi olarak yönetilmeli; systemd ile restart, loglama, izleme (monitoring) konuları düşünülmelidir.
• RAM tüketimi: Veriler RAM’de tutulduğu için düşük bellekli VPS’lerde yanlış yapılandırma problemi büyütebilir.
• Güvenlik: Yanlış yapılandırılmış, internete açık Redis instanceları ciddi güvenlik riskidir. Sadece localhost’tan veya özel ağdan erişime izin vermek gerekir.

Memcached ile Session ve Cache Depolama: Hafif, Hızlı ama Minimalist

Memcached, yine RAM tabanlı, yüksek performanslı bir key–value cache sunucusudur. Redis’e göre daha minimal bir yapıya sahiptir; veri yapıları daha sınırlıdır, fakat cache amaçlı kullanımda fazlasıyla yeterlidir.

Memcached’in güçlü yanları

• Çok hafif ve hızlı: Tasarım itibarıyla basit bir key–value cache olduğundan, latency ve throughput anlamında son derece başarılıdır.
• Yatay ölçekleme kolay: Çok sayıda sunucuya yayılmış Memcached node’larıyla büyük ölçekli cache kümeleri oluşturabilirsiniz.
• Session ve cache için ideal (özellikle kalıcılığın kritik olmadığı, sadece hızın önemli olduğu durumlarda).

Redis v Memcached: Ne zaman hangisi?

Özet bir karşılaştırma yapalım:

Yani:

• Laravel’de queue, rate limiting, pub/sub gibi gelişmiş senaryolarınız varsa Redis ağır basar.
• Sadece cache ve session için, çok basit ve hafif bir çözüm istiyorsanız Memcached gayet iyi bir seçimdir.

WordPress ve WooCommerce özelinde Redis/Memcached tercihlerini ayrıntılı tartıştığımız WordPress ve WooCommerce için Redis mi Memcached mi rehberinde TTL ve eviction ayarları dahil daha derin karşılaştırmalar bulabilirsiniz.

WordPress’te Doğru Session ve Cache Mimarisi Nasıl Kurulur?

WordPress tarafında ana performans kazancını çoğunlukla tam sayfa önbellek ve object cache getirir. Session ise sadece belirli eklentiler için kritik olabilir.

1. Session tarafı

• Standart blog/kurumsal sitelerde genelde session’a aktif ihtiyaç yoktur; varsayılan dosya tabanlı session çoğu zaman problem yaratmaz.
• Üyelik, e-ticaret (WooCommerce), üyelik alanı gibi senaryolarda ise, yoğun giriş/çıkış trafiğinde session dosyalarının IO yükü oluşturduğunu sık görüyoruz.
• Bu durumda, PHP’yi Redis veya Memcached session handler kullanacak şekilde ayarlamak, özellikle sepet ve checkout adımlarında hissedilir hız farkı yaratır.

Örneğin Redis için php.ini ayarı:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=2&prefix=PHPSESSID_"

2. Object cache (WordPress’in asıl kazanç noktası)

WordPress’te özellikle büyük kataloglu WooCommerce sitelerinde veritabanı sorgularının çok ciddi performans maliyeti vardır. Bu maliyeti azaltmanın en etkili yolu, nesne önbelleğini Redis veya Memcached’e taşımaktır. Bu konuda adım adım kurulum ve ayarları detaylandırdığımız WordPress için sunucu tarafı optimizasyon rehberimiz, PHP-FPM, OPcache ve MySQL ile birlikte Redis kullanımını da ele alıyor.

Genel yaklaşım:

• Redis: Büyük kataloglar, yüksek trafik, çok sayıda arka plan sorgusu olan sitelerde tercih edin.
• Memcached: Orta trafikli, nispeten daha basit sitelerde hafif ve iş gören bir seçenek.

3. Tam sayfa önbellek ve mikro önbellekleme

WordPress performansını “uçuran” bir başka katman da tam sayfa önbellektir. PHP’nin önüne konumlanan Nginx veya LiteSpeed, oluşturulmuş HTML çıktısını kısa süreler için (saniyeler–dakikalar) cache’leyebilir.

Nginx tarafında mikro önbellekleme ile PHP yükünü ciddi şekilde azaltabileceğinizi; TTL, bypass ve purge mantığını anlattığımız Nginx mikro önbellekleme rehberimizde detaylarıyla görebilirsiniz.

Özet mimari önerisi:

• Tarafında: Nginx mikro önbellek veya tam sayfa cache eklentisi,
• Uygulama katmanı: PHP-FPM + OPcache,
• Veri katmanı: MySQL/MariaDB + Redis/Memcached object cache,
• Session: Mümkünse Redis/Memcached, en azından dosya sisteminde hızlı disk (NVMe) üzerinde.

Laravel’de Session ve Cache İçin Sağlam Bir Mimari Kurmak

Laravel, doğası gereği stateful bir uygulama framework’ü. Middleware zinciri, auth sistemi, queue’lar, event–listener yapısı derken session ve cache neredeyse her isteğin ortasında yer alıyor.

Ortam bazlı (environment-based) strateji

Laravel projelerinde genelde şu stratejiyi öneriyoruz:

• local / development: SESSION_DRIVER=file, CACHE_DRIVER=file (veya redis ama zorunlu değil)
• staging: Production’a yakın; SESSION_DRIVER=redis, CACHE_DRIVER=redis
• production: Kesinlikle Redis veya Memcached tercih edin; file driver’ı bırakın.

Örnek .env.production kesiti:

APP_ENV=production
APP_DEBUG=false

SESSION_DRIVER=redis
SESSION_LIFETIME=120
SESSION_CONNECTION=redis_session

CACHE_DRIVER=redis
CACHE_STORE=redis_cache

QUEUE_CONNECTION=redis

Connection’ları ayırmak

config/database.php içindeki 'redis' bölümünde farklı connection’lar tanımlayabilirsiniz:

'redis' => [
    'client' => 'phpredis',

    'default' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
    ],

    'cache' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 1,
    ],

    'session' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 2,
    ],
],

Bu sayede:

• Cache temizlerken (ör. php artisan cache:clear) session’ları bozmadan hareket edersiniz,
• Session ile queue verisi birbirine karışmaz,
• İleride farklı Redis örneklerine (fiziksel sunuculara) bölmek isterseniz sorunsuz taşıyabilirsiniz.

Cache türlerine göre sürücü seçimi

Laravel’de sık kullanılan cache pattern’leri:

• query caching: Pahalı sorguları belirli bir süre saklamak,
• config / route cache: Uygulama meta verisini optimize etmek,
• rate limiting: API’leri ve formları kötü niyetli kullanıma karşı korumak,
• feature flags: Özellik açma/kapama mekanizmaları.

Bu tür kullanım senaryolarında Redis, TTL ve gelişmiş veri yapılarıyla esnek çözümler sunar. Memcached ise, çok hafif ve hızlı bir cache katmanı arıyorsanız, özellikle sadece key–value ve TTL ihtiyacı varsa gayet iyi iş görür.

DCHost Altyapısında Dosya, Redis ve Memcached Seçimini Nasıl Kurguluyoruz?

DCHost olarak sağladığımız VPS ve dedicated sunucu altyapılarında, müşterilerimizin session ve cache stratejisini planlarken her zaman şu üç katmanı birlikte değerlendiriyoruz:

• Disk altyapısı: NVMe SSD’ler, dosya tabanlı session ve log’lar için minimum gecikme,
• Bellek ve CPU: Redis/Memcached gibi RAM tabanlı servisler için yeterli kaynak ayrımı,
• Network mimarisi: Uygulama, veritabanı ve cache sunucularının aynı ağda, düşük gecikmeyle haberleşmesi.

Basit tek VPS senaryosunda bile, doğru yapılandırmayla çok şey kazanmak mümkün. Örneğin:

• Tek VPS üzerinde Nginx + PHP-FPM + MySQL + Redis çalıştırarak, WooCommerce mağazalarında ciddi performans artışı sağlamak,
• Laravel tabanlı bir SaaS uygulamasında Redis’i hem session/cache hem de queue için kullanarak, arka plan işler ve gerçek zamanlı bildirimler için stabil bir omurga kurmak.

Daha büyük projelerde ise veritabanı ve cache katmanını ayrı VPS veya dedicated sunuculara bölüp, gerektiğinde colocation senaryolarıyla kendi donanımınızı DCHost veri merkezlerinde barındırarak mimariyi daha da ölçeklenebilir hale getirebilirsiniz.

Karar Verirken Kullanabileceğiniz Pratik Karşılaştırma ve Öneriler

Aşağıdaki tablo, sık karşılaştığımız senaryolar için pratik bir özet sunuyor:

Özet öneriler

• Sürekli session kullanan uygulamalar (Laravel, üyelikli WordPress) için dosya tabanlı session’ı mümkünse bırakın, Redis veya Memcached’e geçin.
• Yüksek sorgu yoğunluklu WordPress/WooCommerce sitelerinde mutlaka object cache’i Redis veya Memcached üzerinde konumlandırın.
• Laravel’de local ortam hariç SESSION_DRIVER=file ve CACHE_DRIVER=file kullanmayın; production’da Redis veya Memcached tercih edin.
• Tek VPS senaryosunda bile Redis/Memcached kurmak TTFB, CPU kullanımı ve yanıt sürelerinde ciddi kazanç sağlar.

Sonuç: “Session + Cache” Mimarisiyle Aynı Donanımdan Daha Fazla Performans Alın

PHP tarafında performans konuşulurken session ve cache depolamasını çoğu zaman ikinci plana atıyoruz. Oysa sahada gördüğümüz tablo net: doğru session/cache stratejisi olmadan PHP-FPM, OPcache ve veritabanı optimizasyonları tam verimle çalışmıyor. Dosya tabanlı session’lar disk IO’yu şişiriyor, veritabanı üzerinde gereksiz yüzlerce sorgu dönüyor, sonuçta ziyaretçileriniz beklemek zorunda kalıyor.

Bu yazıda dosya sistemi, Redis ve Memcached’i WordPress ve Laravel perspektifinden inceledik; hangi projede hangi kombinasyonun mantıklı olduğuna dair pratik öneriler paylaştık. Bir adım öteye geçip, Nginx mikro önbellekleme, PHP-FPM tuning, Redis object cache ve MySQL optimizasyonunu birlikte ele alarak tam bir resim görmek isterseniz; hem WordPress sunucu tarafı optimizasyon rehberimizi hem de Laravel prod ortam optimizasyonu rehberimizi birlikte okumanızı tavsiye ederiz.

Eğer mevcut WordPress veya Laravel projenizde hangi session/cache mimarisine geçmeniz gerektiğine karar veremiyorsanız, DCHost ekibi olarak altyapınızı ve trafik profilinizi birlikte analiz edip; dosya, Redis ve Memcached seçeneklerini gerçek veriler üzerinden tartışabiliriz. Böylece yeni sunucuya geçmeden, sadece yazılım mimarisini ve birkaç ayarı düzelterek bile hissedilir performans artışı sağlamanız mümkün olur.