PHP Session ve Cache: Dosya, Redis, Memcached

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 session ve cache depolamasının türü de özellikle yüksek trafikli sitelerde TTFB’yi (Time To First Byte) ve kullanıcı deneyimini etkileyebilir. Aynı kod ve donanımla elde edilebilecek kazanım, uygulamanın darboğazına bağlıdır; depolama değişikliğinin etkisi ölçülmelidir.

Örneğin, dosya tabanlı session kullanan ve pahalı sorguları önbelleğe almayan varsayımsal bir uygulamayı düşünelim. Trafik arttığında session erişimi veya tekrarlanan sorgular darboğaz oluşturuyorsa admin paneli, sepet ve checkout adımları yavaşlayabilir. Bu durumda “session + cache” mimarisini gözden geçirmek yararlı olabilir; ancak bu belirtiler tek başına depolama kaynaklı bir sorunu kanıtlamaz.

Bu yazıda PHP session ve uygulama cache depolaması için dosya sistemi, Redis ve Memcached seçeneklerini WordPress ve Laravel açısından karşılaştırıyoruz. Laravel örnekleri Laravel 13.x, PHP 8.3+ ve tek bir bağımsız Redis sunucusu içindir; Redis Cluster tarifi değildir. Native PHP session örneği ayrıca PhpRedis session handler’ını kullanır. Framework yükseltmek mevcut uygulamanızın config dosyalarını kendiliğinden yeni proje şablonuyla eşitlemez; kurulu sürümü ve gerçek yapılandırmayı kontrol edin.

Ö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:

• Native PHP session kullanan bir eklentide kullanıcıya ait geçici durum
• Laravel’in oturum kullanan web akışında kimlik doğrulama ve çok adımlı form bilgileri
• İlgili framework akışında CSRF token’ı gibi oturuma bağlı değerler

Sunucuda tutulan session verisi kullanıcıya veya tarayıcı oturumuna özeldir; tarayıcıdaki bir kimlik çerezi ilgili kayda ulaşmayı sağlar. Saklama süresi, çerez ömrü ve geçersiz kılma davranışı birlikte tasarlanır. Bu rehber sunucu tarafındaki depoları karşılaştırır; Laravel’in cookie driver’ı gibi farklı modeller de vardır.

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 gibi kullanıcıya özel veriler ise ortak önbelleğe karıştırılmadan, kullanıcı/oturum ayrımı ve güncellik kurallarıyla ele alınmalıdır.
• Laravel’de pahalı sorguların, API cevaplarının veya hesaplamaların önbelleğe alınması.

Yeniden üretilebilir cache verisi kaybolduğunda uygulama doğru kaynaktan veriyi yeniden üretmelidir. Ancak cache sunucusuna bağlantı hatası otomatik olarak güvenli bir cache miss veya fallback demek değildir; kullanılan sürücü ve hata işleme önemlidir. Session, kilit, rate-limit sayacı ve queue verisini sıradan silinebilir cache ile aynı kayıp toleransına sahip varsaymayın.

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

Pratikte tablo şu şekilde:

• WordPress: Çekirdeğin giriş çerezleri ve token yönetimi native PHP session dosyalarından farklıdır. WooCommerce’in varsayılan session handler’ı kendi çerezini ve woocommerce_sessions tablosunu kullanır; object cache bu veriye erişimde rol oynayabilir. PHP ini ayarını değiştirmek bu tabloyu otomatik olarak Redis’e taşımaz.
• Laravel: Session ve uygulama cache sürücüleri ayrı seçilir; queue’nun da kendi bağlantı ayarı vardır. config:cache/route:cache ise derlenen yapılandırma/route dosyalarıdır ve Redis cache driver seçimiyle aynı işlem değildir. Her API isteğinin session kullanması gerekmez.

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: Basit ama Sınırlı

Native PHP’nin varsayılan session handler’ı files olsa da bu, her WordPress ziyaretçisinin session dosyası oluşturduğu veya Laravel 13’ün varsayılanının file olduğu anlamına gelmez. Laravel 13 proje şablonunda session ve cache varsayılanları database’dir. Native PHP için şu dizin yalnızca örnektir; uygulamanın PHP-FPM kullanıcısına uygun, diğer kullanıcıların session dosyalarını listeleyemediği bir dizin ve temizleme politikası gerekir:

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

Dosya tabanlı session’ın artıları

• Ek daemon gerektirmez: Uygun dizin ve izinler sağlanmışsa ayrı Redis/Memcached servisi kurulmaz.
• Basit iş yükleri için adaydır: Tek sunucuda ölçülen gecikme, eşzamanlılık ve kapasite uygunsa üretimde de kullanılabilir.
• İncelenebilir dosyalar: Yetkili inceleme mümkündür; session içeriğini veya kimliklerini herkese açık log ve çıktılara koymayın.

Dosya tabanlı session’ın eksileri

• Disk IO bağımlılığı: Dosya tabanlı session erişimleri depolama yükü oluşturabilir. paylaşımlı hosting veya yoğun VPS’lerde depolama darboğazı varsa IO wait artabilir.
• Yüksek eşzamanlılıkta kilit bekleme: Aynı session’a erişen eşzamanlı istekler (özellikle AJAX yoğun sayfalarda), session kilidi tutulduğu sürece birbirini bekleyebilir.
• Multi-node mimarilerde sorun: Birden çok PHP sunucusunda ortak session depolaması için session.save_path’i paylaşılan bir dosya sistemine (NFS vb.) yönlendirmek bir seçenektir. Bu yaklaşım ekstra karmaşıklık ve gecikme getirebilir.

Buradaki dosya kilidi açıklaması native PHP files handler’ına aittir. Native PHP’de tüm session yazıları bittikten sonra session_write_close() kilit süresini kısaltabilir; sonrasında yapılan değişikliklerin kendiliğinden kaydedildiğini varsaymayın. Laravel varsayılan olarak aynı session’ın isteklerini eşzamanlı çalıştırır; kayıp güncelleme riski varsa framework’ün desteklenen session blocking yaklaşımını ayrıca değerlendirin. Redis’e geçiş bu iki farklı kilit modelini otomatik olarak çözmez.

Dosya tabanlı cache’in sınırları nelerdir?

Dosya tabanlı cache’i değerlendirirken şu sınırlamalar dikkate alınmalıdır:

• Diskteki rastgele okuma/yazma gecikmesi, bellek tabanlı depolamaya göre daha yüksek olabilir; fark donanıma ve iş yüküne bağlıdır,
• Dosya sayısı arttıkça dizin yönetimi ve temizlik zorlaşabilir,
• Düşük gecikme hedeflenen yoğun okuma/yazma senaryolarında disk erişimi dar boğaz oluşturabilir.

Dosya tabanlı depolama düşük karmaşıklık sağlayabilir; seçim yalnızca trafik etiketiyle yapılmaz. Birden çok sunucuda paylaşım, geçici/container disklerinin ömrü ve node kaybında oturum sürekliliği planlanmalıdır. Redis ve Memcached ortak erişim sağlar, buna karşılık yeni ağ ve servis bağımlılıkları ekler.

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

Redis, bellek üzerinde anahtarlar ve veri yapıları tutan, yapılandırmaya göre diske kalıcılık sağlayabilen bir sunucudur. Cache, session ve Redis queue entegrasyonları farklı veri ömrü ve kayıp toleransları gerektirir; aynı sunucuda kullanılabilmeleri aynı politikanın hepsine uygun olduğu anlamına gelmez.

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ı

• Düşük gecikme potansiyeli: RAM erişimi yararlı olabilir; ağ, komut ve yük toplam gecikmeyi belirler.
• Veri yapıları: String, list, set, sorted set ve hash gibi yapılar ile sayaçlar sunar. Tek atomik komut, uygulamadaki çok adımlı akışın tamamını otomatik olarak atomik yapmaz.
• TTL ve eviction: Anahtar süresi ile bellek sınırında anahtar atma ayrı konulardır. Session/queue anahtarları da yanlış politikadan etkilenebilir.
• RDB/AOF: Yeniden başlatma sonrası kurtarmaya yardımcı olur; ayarlara göre yakın zamandaki yazılar kaybolabilir. Kalıcılık, yedek veya kesintisiz erişim garantisi değildir.

WordPress’te Redis kullanımı

WordPress ekosisteminde Redis genellikle nesne önbelleği (object cache) için devreye alınır. Çekirdek ve eklentilerin object cache API’si üzerinden önbelleğe aldığı veriler bu katmandan okunabilir. Varsayılan object cache yalnızca istek boyunca yaşar; Redis ile istekler arasında kalıcılık için uygun bir entegrasyon gerekir. Bu, bütün veritabanı sorgularının otomatik olarak önbelleğe alınması anlamına gelmez.

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, önbellekten karşılanabilen tekrar eden sorguların yükünü azaltabilir. Bu, aynı VPS veya dedicated sunucu üzerindeki eşzamanlı istek kapasitesine katkı sağlayabilir; kazanım, önbellek isabet oranına ve diğer darboğazlara bağlıdır.

Laravel’de Redis kullanımı

Laravel 13’te Redis, uygun istemciyle cache, session ve queue sürücülerinde kullanılabilir. PhpRedis PHP uzantısı bir seçenektir; predis/predis Composer paketiyle REDIS_CLIENT=predis de desteklenir. Bu alternatif native PHP’nin session.save_handler=redis örneğini tek başına sağlamaz; o örnek PhpRedis uzantısının handler’ını gerektirir.

Aşağıdaki .env kesiti ile ilerideki config/database.php örneği birlikte kullanılmalıdır. Çalışan yerel Redis, uygun yetkili app hesabı ve gerçek parola önkoşuldur; yer tutucuyu kendi gizli değerinizle değiştirin ve dosyayı sürüm kontrolüne koymayın. Her uygulama/ortam için uygun prefix ve depolama ayırın. Bu, mevcut oturumları veya kuyruktaki işleri taşıyan bir migration komutu değildir:

SESSION_DRIVER=redis
SESSION_CONNECTION=session
SESSION_STORE=redis

CACHE_STORE=redis
REDIS_CACHE_CONNECTION=cache
REDIS_CACHE_LOCK_CONNECTION=default

QUEUE_CONNECTION=redis
REDIS_QUEUE_CONNECTION=queue

REDIS_CLIENT=phpredis
REDIS_HOST=127.0.0.1
REDIS_USERNAME=app
REDIS_PASSWORD=REPLACE_WITH_YOUR_REDIS_PASSWORD
REDIS_PORT=6379
REDIS_PREFIX=dchost_app_
REDIS_DB=0
REDIS_CACHE_DB=1
REDIS_SESSION_DB=2
REDIS_QUEUE_DB=3

CACHE_STORE=redis, config/cache.php içindeki stores.redis store’unu seçer; REDIS_CACHE_CONNECTION=cache bu store’u Redis bağlantısı cache ile bağlar. SESSION_CONNECTION=session session sürücüsünün, REDIS_QUEUE_CONNECTION=queue Redis queue sürücüsünün bağlantısını seçer. REDIS_SESSION_DB ve REDIS_QUEUE_DB özel adlardır: aşağıdaki config bunları env() ile okumazsa yalnızca .env’e yazmak yeterli değildir.

Bağımsız Redis’te DB 1/2/3 anahtar isim alanlarını ve DB’ye yönelik temizliği ayırır; aynı sürecin RAM, CPU, maxmemory, eviction, arıza ve RDB/AOF dosyaları ortaktır. Prefix veya DB index bir yetki/güvenlik sınırı değildir. Redis Cluster yalnızca DB 0 destekler ve bu DB index tarifi orada uygulanmaz. Kaynak/eviction ayrımı gerekiyorsa ayrı Redis instance’ları değerlendirin.

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ı

• Servis yönetimi: İstemci uyumu, timeout, bağlantı hataları, izleme ve planlı yeniden başlatma/kurtarma testleri gerekir.
• Bellek bütçesi: Dataset yanında bağlantılar, persistence/replication tamponları ve aynı VPS’teki PHP/veritabanı ihtiyacını hesaplayın. maxmemory bütün süreç RSS’sinin tavanı değildir.
• Erişim: Redis’i güvenilmeyen ağlara açmayın; izin verilen istemcileri, ACL/kimlik doğrulamayı ve ağ üzerinden erişimde gerekli TLS desteğini doğrulayın. Localhost veya özel ağ tek başına bütün yetkilendirme ihtiyacını çözmez.

Memcached ile Session ve Cache Depolama

Memcached, anahtar ve değer odaklı bir cache sunucusudur. Standart kullanımda veriler bellek üzerindedir ve uygulama kaybı/cache miss durumunu karşılamalıdır. Redis’in veri yapıları ve queue entegrasyonlarıyla aynı özellik setini sunmaz; seçimi gerçek istemci desteği ve iş yükü belirler.

Memcached’in güçlü yanları

• Basit cache modeli: Anahtar/değer ve TTL ihtiyaçları için bir adaydır; gecikme ve kapasiteyi ölçün.
• Dağıtım: Uygun istemci/proxy anahtarları birden fazla sunucuya dağıtabilir. Dağıtım otomatik replikasyon veya session dayanıklılığı demek değildir.
• Session desteği: Uyumlu Laravel/native PHP sürücüsüyle kullanılabilir; eviction, node kaybı veya yeniden başlatmada oturum kaybını uygulamanın kabul edip etmediğini değerlendirin.

Redis ve Memcached: Ne Zaman Hangisi?

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

Memcached’in isteğe bağlı warm restart özelliği uyumlu temiz yeniden başlatmalarda cache’i koruyabilir; crash-safe değildir. Extstore değerleri flash’a taşıyabilir, anahtarlar bellekte kalır. Bu özellikler session kaybı tasarımını ortadan kaldırmaz. Memcached erişimini güvenilen istemciler ve desteklenen bağlantı yöntemleriyle sınırlandırın; servisi internete veya güvenilmeyen kullanıcılara doğrudan açmayın.

Yani:

• Laravel Redis queue veya Redis’e özgü işlemler gerekiyorsa ilgili Redis entegrasyonunu değerlendirin. Horizon, Redis destekli Laravel queue’larını izler; başka queue backend’lerinin genel izleyicisi değildir ve Laravel 13 belgesinde Redis Cluster ile uyumlu değildir.
• Yeniden üretilebilir key–value cache için Memcached uygun bir seçenek olabilir. Session için desteklenen sürücü, eşzamanlı güncellemeler ve veri kaybı toleransı ayrıca test edilmelidir.

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’te sayfa önbelleği, object cache ve eklentilerin session depolarını ayrı inceleyin. Kazanım, hangi yolun gerçekten darboğaz olduğuna bağlıdır. WordPress/WooCommerce varsayılan davranışı ile native PHP session kullanan başka bir eklentinin davranışı aynı değildir.

1. Session tarafı

• Standart WordPress oturum açma işlemini native PHP session dosyalarına eşitlemeyin; session kullanan eklenti varsa kendi handler’ını tespit edin.
• WooCommerce’in varsayılan handler’ı kendi veritabanı tablosunu ve session çerezini kullanır. Object cache eklemek veya PHP ini değiştirmek tüm sepet/checkout durumunu Redis’e taşımaz.
• Yalnızca native PHP session kullanan uyumlu bir bileşen için PhpRedis/Memcached handler geçişi planlayın; mevcut oturumlar, serileştirme, kilitler ve geri dönüş davranışını staging’de sınayın.

Aşağıdaki bağımsız örnek native PHP session kullanan uygulama içindir; Laravel session config’inin veya WooCommerce handler’ının yerine geçmez. İlgili PHP-FPM SAPI’sinde PhpRedis handler’ı etkin olmalı; yerel Redis hesabı ve izinleri hazır olmalıdır. Parola yer tutucusunu URI sorgusuna uygun kodlanmış gerçek değerle değiştirin; istemciyi ve erişim hedefini test edin:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=2&prefix=PHPSESSID_&auth[]=app&auth[]=REPLACE_WITH_URL_ENCODED_PASSWORD&timeout=2.5"
redis.session.locking_enabled = 1

PhpRedis belgelerinde session locking varsayılan olarak kapalıdır; bu örnek açar. Kilit süresi, bekleme aralığı ve retry ayarlarını en uzun gerçek istek ve timeout bütçesiyle test edin; kilidin erken bitmesi veya sınırsız bekleme kayıp güncelleme/kesinti oluşturabilir. Bu kilitleme açıklaması tek master düzeni içindir; RedisArray/Cluster’a genellenmez. Native PHP session ömrü session.gc_maxlifetime ile saniye, Laravel SESSION_LIFETIME ise dakika cinsindedir.

2. Object cache katmanı

Tekrarlanan ve object cache API’sinden yararlanan işlemler Redis/Memcached entegrasyonuyla veritabanı yükünü azaltabilir. Bu bütün SQL sorgularını otomatik olarak cache’lemez; indeks, sorgu ve eklenti davranışı da önemlidir. WordPress için sunucu tarafı optimizasyon rehberimiz PHP-FPM, OPcache ve veritabanı katmanlarını birlikte değerlendirmek için tamamlayıcıdır.

Genel yaklaşım:

• Redis: Desteklenen eklenti/istemci, gerekli özellikler, bellek ve işletim planı uygunsa değerlendirin.
• Memcached: Entegrasyonun desteklediği yeniden üretilebilir cache iş yükünde ölçün. Trafik veya katalog boyutu tek başına seçimi belirlemez.

3. Tam sayfa önbellek ve mikro önbellekleme

Tam sayfa önbellek, uygun public HTML cevaplarını tekrar kullanarak PHP çalışmasını azaltabilir. Sepet, checkout, hesap, session’a özel veya kişiselleştirilmiş API cevapları için uygun bypass ve invalidation kuralları gerekir; anonim ziyaretçinin de özel sepet durumu olabilir. Object cache ile sayfa cache’inin anahtarları ve ömürleri aynı şey değildir.

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:

• Ön katman: Yalnızca cache’lenebilir public cevaplar için desteklenen sayfa/mikro cache
• Uygulama: Ölçülmüş PHP-FPM eşzamanlılığı ve OPcache
• Veri: Veritabanı ve ihtiyaca göre Redis/Memcached object cache
• Session: Bileşenin gerçek handler’ı; uyumluluk ve süreklilik gereksinimi doğrulanmış depo

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

Laravel web oturumları, application cache, queue ve stateless/token tabanlı API akışları farklı ihtiyaçlara sahiptir. Session middleware’i olmayan her isteği stateful saymayın. Buradaki örnek Laravel 13 web session’ı, Redis application cache ve Redis queue için açık bağlantılar tanımlar.

Ortam bazlı (environment-based) strateji

Laravel projelerinde genelde şu stratejiyi öneriyoruz:

• Local: İhtiyaca göre SESSION_DRIVER=file ve CACHE_STORE=file veya database/Redis kullanılabilir; seçim test ihtiyacına bağlıdır.
• Staging: Production sürücülerini, istemciyi ve topolojiyi mümkün olduğunca temsil etsin; farklı hesap, prefix ve depolar kullanın.
• Production: Dosya/database seçeneği otomatik olarak yanlış değildir. Çok node, gecikme, kurtarma ve işletim gereksinimleri ortak depoyu gerektiriyorsa uyumlu Redis/Memcached/database tasarımını ölçerek seçin.

Önceki bağlantı kesitine eklenecek production örneği aşağıdadır; 120 dakikalık idle session süresi uygulama politikanızla doğrulanacak bir örnektir. HTTPS doğru sonlandırılmalı ve proxy güven ayarları uyumlu olmalıdır. Dosyanın adını yalnızca .env.production yapmak veya içine APP_ENV=production yazmak onu otomatik seçtirmez: Laravel ortam dosyasını yüklemeden önce dışarıdan gelen APP_ENV veya CLI --env seçimine bakar; yoksa .env kullanır.

APP_ENV=production
APP_DEBUG=false

SESSION_DRIVER=redis
SESSION_CONNECTION=session
SESSION_STORE=redis
SESSION_LIFETIME=120
SESSION_SECURE_COOKIE=true
SESSION_HTTP_ONLY=true
SESSION_SAME_SITE=lax

CACHE_STORE=redis
REDIS_CACHE_CONNECTION=cache
REDIS_CACHE_LOCK_CONNECTION=default

QUEUE_CONNECTION=redis
REDIS_QUEUE_CONNECTION=queue

Connection’ları ayırmak

config/database.php dosyasının redis bölümüne yönelik aşağıdaki bağımsız-sunucu örneğinde dört bağlantı adı kullanılır. Bu, dosyanın tamamı değildir; mevcut uygulamanızın diğer database ayarlarını ve gerekli Redis TLS/URL/retry seçeneklerini koruyarak birleştirin. Aynı alanları etkileyen mevcut REDIS_URL veya özelleştirmeler varsa gerçek hedefi ayrıca doğrulayın:

'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),
    'options' => [
        'prefix' => env('REDIS_PREFIX', 'dchost_app_'),
    ],

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

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

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

    'queue' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'username' => env('REDIS_USERNAME'),
        'password' => env('REDIS_PASSWORD'),
        'port' => (int) env('REDIS_PORT', 6379),
        'database' => (int) env('REDIS_QUEUE_DB', 3),
    ],
],

Laravel 13 proje şablonundaki config/cache.php, config/session.php ve config/queue.php ilgili selector’ları okumalıdır. Eski/özelleştirilmiş projede CACHE_DRIVER hâlâ okunuyor olabilir; değişken adı kendi config’iniz tarafından belirlenir. Yukarıdaki örneğin sonucu:

• cache bağlantısı DB 1, session DB 2, queue DB 3; default DB 0 kullanır. Cache kilit bağlantısı örnekte default olarak açıkça seçilmiştir.
• php artisan cache:clear redis hedef Redis cache store’unun seçili DB’sini temizler; prefix’e göre daraltmaz. Doğru eşleşmede DB 2/3’teki oturum/işler bu DB 1 temizliğinin hedefi değildir. Aynı DB’yi paylaşan diğer anahtarlar silinebilir; üretimde deneme amaçlı çalıştırmayın.
• DB ayrımı RAM/eviction veya arıza ayrımı sağlamaz. Aynı instance’ta bellek politikasının session/queue verisini nasıl etkilediğini test edin; ayrı instance’ta da host kaynakları ortak olabilir.
• Geçişte mevcut session kimlikleri/serileştirme, APP_KEY ve cookie ayarları, cache’in yeniden dolması ve bekleyen işler planlanmalıdır. Depo değişikliği eski veriyi otomatik taşımaz; gerekirse kontrollü yeniden giriş ve geri dönüş planı hazırlayın.

Değişiklikleri önce staging’de uygulayın. Production deployment’ında doğrulanmış config’i php artisan config:cache ile yeniden üretin; .env değişikliği eski config cache’i kendiliğinden değiştirmez. İlgili uzun yaşayan worker/Horizon süreçlerinin yeni config’i almasını planlı deployment akışında sağlayın. Geri dönüşte eski config/bağlantılarla yeni yazılan verinin uyumunu da doğrulayın.

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

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

• Query/API cache: Yeniden üretilebilir sonuçlar için doğru anahtar, TTL ve invalidation
• Config/route cache: Deployment sırasında yerel dosyaya derlenen framework ayarları; Redis application cache değildir
• Rate limiting: İstek politikaları için uygun cache store ve eşzamanlılık davranışı
• Feature flags: Kaynak sistemden gelen kararların ömrü ve güncelleme kuralları

Application cache için Redis veya Memcached, ihtiyaç duyulan işlemler ve entegrasyonla seçilir. TTL dolmadan eviction olabilir; miss’te yeniden üretim ve bağlantı hatasında davranış ayrı test edilir. Config/route cache’i Redis seçerek etkinleştirmiş olmazsınız.

DCHost Altyapısında Depolama Seçimini Planlamak

VPS veya dedicated sunucuda session/cache tasarlarken planın verdiği kontrol ve kaynakları şu katmanlarla birlikte değerlendirin:

• Disk: Session dosyaları, persistence ve log’lar için ölçülen gecikme, kapasite ve yedek/kurtarma ihtiyacı
• Bellek/CPU: PHP, veritabanı, cache, queue ve işletim sistemini kapsayan ortak bütçe
• Ağ: Uygulama-depo bağlantılarında gecikme, erişim izinleri, şifreleme ve arıza davranışı

Tek VPS için değerlendirilebilecek iki varsayımsal mimari:

• WordPress/WooCommerce: Web sunucusu, PHP-FPM ve veritabanına ek olarak, tekrar eden object-cache işlemleri için desteklenen Redis/Memcached entegrasyonu
• Laravel SaaS: Açıkça eşlenmiş session/cache/queue bağlantıları ve Redis queue kullanılıyorsa uyumlu Horizon kurulumu; her rol için bellek ve kurtarma politikası

Ölçülen kapasite veya işletim gereksinimleri bunu gerektiriyorsa uygulama, veritabanı ve cache rollerini ayrı VPS/dedicated sunuculara ayırabilirsiniz. Colocation da yönetim sorumluluğu ve maliyeti farklı bir seçenektir. Ek node; ağ, yedekleme, failover ve veri tutarlılığı gereksinimleri getirir, tek başına yüksek erişilebilirlik sağlamaz.

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

Tablo zorunlu sürücü önerisi değil, aynı kriterlerle değerlendirilecek senaryoları özetler:

Özet öneriler

• Önce native PHP, WordPress/WooCommerce ve Laravel handler’larını ayırın.
• Dosya, Redis ve Memcached’i temsilî yük ve gerçek bağlantı/istemci desteğiyle karşılaştırın.
• Laravel store, connection ve DB index adlarını tek tek doğrulayın; Cluster’da DB 0 sınırını ve Horizon uyumluluğunu dikkate alın.
• Cache miss, session kaybı, queue kaybı ve servis hatasının farklı sonuçlarını test edin; ölçülmemiş TTFB/kullanıcı kapasitesi vaadiyle karar vermeyin.

Sonuç: Session ve Cache İçin Ölçülebilir Bir Seçim

Session ve cache seçimi, PHP-FPM/OPcache/veritabanı ayarlarıyla birlikte değerlendirilir; tek bir backend bütün performans sorunlarını çözmez. Önce doğru state sahibini ve yavaş yolu bulun, sonra depoyu değiştirmenin maliyetini ve hata davranışını ölçün.

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.

Karar öncesinde mevcut config’i ve geri dönüş yolunu kaydedin. Staging’de login/logout, CSRF ve form akışlarını, misafir/üyeli sepeti, eşzamanlı session güncellemelerini, cache temizliğini, istemci bağlantı hatalarını ve planlı yeniden başlatmayı sınayın. Aynı temsilî yükte TTFB, sorgu süreleri, cache hit/miss, bağlantı hataları ve kaynak kullanımını karşılaştırın; debug araçlarını erişim kontrolüyle kullanın. Sonucu verilerle değerlendirin, yalnızca backend adı veya disk etiketiyle değil.

Birincil Teknik Kaynaklar

• Laravel 13 — Redis
• Laravel 13 — Sessions
• Laravel 13 — Cache
• Laravel 13 — Horizon
• Redis — SELECT and logical databases
• Redis — Key eviction
• PhpRedis — PHP session handler
• WordPress — Object Cache