---
title: "WordPress Nesne Önbelleği: Redis, Memcached veya Hiçbiri"
url: https://bw.agency/blog/wordpress-nesne-onbellegi/
date: 2026-05-02
modified: 2026-05-02
author: "bwa"
description: "Her WordPress sayfa yüklemesi onlarca veritabanı sorgusu çalıştırır. Seçenekler, kullanıcı meta verileri, transient'ler, yazı verileri — aynı şeyler tekrar tekrar çekilir. WordPress object cache tam da burada devreye girer: sorgu sonuçlarını bellekte saklayarak WordPress'in her seferinde veritabanına gitmesini engeller."
categories:
  - "WordPress"
image: https://img.poweredcache.net/bw.agency/wp-content/nexter-optimizer/uploads/2026/05/wordpress-object-cache.avif.webp?ssl=1
word_count: 1163
---

# WordPress Nesne Önbelleği: Redis, Memcached veya Hiçbiri

**Her WordPress sayfa yüklemesi onlarca veritabanı sorgusu çalıştırır.** Seçenekler, kullanıcı meta verileri, transient'ler, yazı verileri — aynı şeyler tekrar tekrar çekilir. WordPress object cache tam da burada devreye girer: sorgu sonuçlarını bellekte saklayarak WordPress'in her seferinde veritabanına gitmesini engeller.

Ancak çoğu "Redis vs Memcached" makalesi yanlış yapıyor — object cache'in gerçekte ne yaptığını açıklamadan doğrudan karşılaştırmaya atlıyorlar. Bunu düzeltelim.

## WordPress Object Cache Gerçekte Ne Yapar?

**WordPress 2.5'ten bu yana yerleşik bir object cache'e sahiptir.** WordPress her bir seçenek getirdiğinde, yazı meta verisi yüklediğinde veya kullanıcı verisi aldığında, sonucu `wp_cache_set()` ile bir PHP dizisinde saklar. Aynı veri tekrar gerektiğinde `wp_cache_get()` çağrısıyla başka bir SQL sorgusu çalıştırmak yerine bellekten alır.

Çoğu kişinin kaçırdığı nokta şu — **varsayılan object cache yalnızca tek bir istek süresince yaşar.** Sayfa yüklenmeyi bitirdiğinde, önbelleğe alınmış tüm veri kaybolur. Bir sonraki ziyaretçi aynı sorguları baştan tetikler.

Bu, varsayılan davranıştır. Eklenti gerekmez. WordPress bunu kutudan çıktığı haliyle yapar.

**Kalıcı (persistent) object cache oyunu değiştirir.** Veriyi istekle birlikte ölen bir PHP dizisinde saklamak yerine, Redis veya Memcached gibi harici bir bellek deposunda saklar. Artık önbelleğe alınmış veri istekler arasında hayatta kalır. Ziyaretçi A ana sayfayı yükler ve önbelleği doldurur. Ziyaretçi B, veritabanına hiç dokunmadan önbelleğe alınmış sürümü alır.

Mekanizma bir WordPress "drop-in"ıdır — `wp-content/` klasörüne yerleştirilen `object-cache.php` adlı özel bir dosya. WordPress her istekte bu dosyayı kontrol eder. Varsa, varsayılan `WP_Object_Cache` sınıfı yerine onu kullanır. Redis veya Memcached eklentileri sisteme bu şekilde bağlanır.

## Kalıcı Object Cache'e Gerçekten Ne Zaman İhtiyacınız Var?

### İhtiyacınız olan durumlar

- Siteniz WooCommerce veya oturum açmış kullanıcılarla çalışan bir üyelik eklentisi kullanıyorsa (sayfa önbelleği kimliği doğrulanmış isteklerde pek yardımcı olmaz)

- Karmaşık sorgulara sahip yüksek trafikli bir siteniz varsa — özellikle sayfa önbelleğine alınamayan dinamik sayfalar

- Yönetim paneliniz yavaşsa — object cache arka ucu dramatik şekilde hızlandırır

- Sayfa başına yüzlerce veritabanı sorgusu görüyorsanız

### İhtiyacınız olmayan durumlar

- Çoğunlukla anonim ziyaretçilere ve bir sayfa önbelleği eklentisine sahip basit bir blog işletiyorsanız

- Hosting'iniz Redis veya Memcached desteklemiyorsa (paylaşımlı hosting genellikle desteklemez)

- Günlük 1.000'den az ziyaretçiniz varsa ve karmaşık eklenti kullanmıyorsanız

Object cache, sayfa önbelleğini tamamlar — onun yerini almaz. Sayfa önbelleği tam HTML sayfaları sunar. Object cache ise sayfa önbelleğine alınamayan içerik için veritabanı sorgularını azaltır.

## Redis vs. Memcached: Gerçek Farklar

### Veri Kalıcılığı

**Redis veriyi diske yazabilir.** Redis sunucunuz yeniden başlarsa, önbellek son anlık görüntüden geri yüklenebilir. Memcached tamamen bellek içidir — yeniden başlatın ve her şey gider.

WordPress için bu, düşündüğünüzden daha az önemlidir. Soğuk bir önbellek birkaç sayfa yüklemesiyle kendini yeniden oluşturur. Ancak milyonlarca önbellek anahtarına sahip büyük bir WooCommerce mağazası işletiyorsanız, sıcak yeniden başlatma güzel bir özellik.

### Veri Yapıları

**Redis** string, liste, küme, sıralı küme, hash ve daha fazlasını destekler. **Memcached** yalnızca anahtar-değer çifti ve string değerlerle sınırlıdır.

Temel WordPress object cache'i için bu fark çoğunlukla önemsizdir — WordPress her iki durumda da serileştirilmiş PHP verisini string olarak saklar. Ancak önbelleği doğrudan kullanan özel işlevsellik oluşturuyorsanız, Redis daha fazla esneklik sunar.

### Bellek Yönetimi

**Memcached** bir slab allocator kullanır. Belleği parçalar halinde önceden ayırır ve öğeleri en yakın eşleşen slab boyutuna atar. Verimlidir ancak önbelleğe alınan öğeleriniz boyut olarak çok farklılık gösterdiğinde bellek israfına neden olabilir.

**Redis** standart sistem allocator'ları (varsayılan olarak jemalloc) kullanarak talep üzerine bellek ayırır. Daha esnek, ancak zamanla parçalanabilir.

Her ikisi de maksimum bellek sınırı belirlemenize izin verir. Her ikisi de sınıra ulaştığında eski anahtarları çıkarır. Redis daha fazla çıkarma politikası sunar (LRU, LFU, rastgele, volatile-tabanlı).

### Replikasyon ve Yüksek Erişilebilirlik

**Redis** yerleşik replikasyona sahiptir. Otomatik yük devretme için Redis Sentinel veya yatay ölçeklendirme için Redis Cluster kurabilirsiniz. **Memcached**'in yerel replikasyonu yoktur — harici araçlara ihtiyacınız olur.

Çoğu WordPress sitesi için bu abartılı. Ancak bir yük dengeleyici arkasında yüksek erişilebilirlik kurulumu çalıştırıyorsanız, Redis altyapıyı basitleştirir.

### Gözlemlenebilirlik

**Redis burada kazanır.** Anahtarları inceleyebilir, anahtar başına bellek kullanımını kontrol edebilir, `MONITOR` ile komutları gerçek zamanlı izleyebilir ve `INFO` ile ayrıntılı istatistikler alabilirsiniz. Memcached'in `stats` komutu temel bilgileri verir ancak tek tek anahtarları veya boyutlarını kolayca göremezsiniz.

### WordPress Eklenti Ekosistemi

**Redis daha iyi WordPress eklenti desteğine sahiptir.** Object Cache Pro (ücretli) ve Redis Object Cache (ücretsiz) olgun ve iyi bakımlıdır. Memcached için seçenekler daha sınırlı ve daha az aktif geliştirilmektedir.

## Hız Karşılaştırma

| Özellik | Redis | Memcached |
| -------- | ----- | --------- |
| Veri kalıcılığı | Evet (RDB/AOF) | Hayır |
| Veri yapıları | String, liste, küme, hash vb. | Yalnızca string |
| Replikasyon | Yerleşik (Sentinel, Cluster) | Yok (harici araç gerektirir) |
| Bellek verimliliği | İyi, parçalanabilir | İyi, slab allocator |
| Maks. bellek çıkarma | 6 politika (LRU, LFU vb.) | Yalnızca LRU |
| Anahtar inceleme | Tam (SCAN, DEBUG OBJECT) | Sınırlı |
| Çoklu iş parçacığı | Tek iş parçacıklı (6.0+'da I/O threadleri) | Çoklu iş parçacıklı |
| WordPress eklentileri | Mükemmel | Sınırlı |

## Öneri

**Redis kullanın.** Temel anahtar-değer işlemleri için daha hızlı olduğundan değil — anlamlı bir fark yok. Ancak ekosistemi, hata ayıklama araçları ve WordPress eklenti seçenekleri daha iyi bakımlı olduğu için.

Memcached'i tercih edeceğim tek senaryo: sunucunuzda zaten çalışıyor ve altyapıya dokunmak istemiyorsanız. Sıfırdan kurulum yapıyorsanız, Redis doğru tercih.

## Object Cache'inizin Çalıştığını Doğrulayın

### Drop-in Durumunu Kontrol Edin

WP yönetim panelinde **Eklentiler → Drop-in'ler**'e gidin. `object-cache.php` dosyasının orada listelendiğini görmelisiniz. Eksikse, önbellek eklentiniz ne derse desin kalıcı önbellek aktif değildir.

WP-CLI ile de kontrol edebilirsiniz: `wp cache type` komutu `Redis` veya `Memcached` döndürmelidir. `WP_Object_Cache` diyorsa, varsayılan kalıcı olmayan önbelleği çalıştırıyorsunuz.

### İsabet Oranlarını Kontrol Edin

**Sağlıklı bir object cache %85'in üzerinde isabet oranına sahip olmalıdır.** Daha düşük rakamlar görüyorsanız, bir sorun var — ya önbellek çok küçük, anahtarlar çok hızlı sona eriyor ya da bir eklenti sürekli önbelleği temizliyor.

Redis ile komut satırından kontrol edebilirsiniz: `redis-cli INFO stats | grep keyspace`. `keyspace_hits` ve `keyspace_misses` sayıları gerçek durumu anlatır. Hesaplama: `hits / (hits + misses) × 100`.

## Sık Karşılaşılan Sorunlar

### object-cache.php Çakışması

Aynı anda yalnızca bir `object-cache.php` drop-in'i var olabilir. Redis Object Cache yüklerseniz ama zaten bir Memcached drop-in'i veya yönetilen hosting sağlayıcınızın kendi drop-in'i varsa, çakışma yaşarsınız. Kurulumdan önce `wp-content/object-cache.php` dosyasının zaten var olup olmadığını ve kimin koyduğunu kontrol edin.

### Düşük Bellek Sınırları

Varsayılan Redis `maxmemory` genellikle 64MB'dır. Bir WooCommerce mağazası veya çok eklentili bir site için bu hızla dolar. Dolduğunda Redis anahtar çıkarmaya başlar, isabet oranınız düşer ve veritabanını yeniden zorlamaya başlarsınız. Çoğu WordPress sitesi için 128-256MB iyi bir başlangıç noktasıdır.

### Canlıda SAVEQUERIES ve WP_DEBUG

`WP_DEBUG` veya `SAVEQUERIES` etkinse, Object Cache Pro ve benzeri eklentiler her önbellek işlemi için backtrace saklar. Bu son derece bellek yoğundur ve bellek tükenmesinden PHP ölümcül hatalarına neden olabilir. Canlıda asla çalıştırmayın. `wp-config.php` dosyanızda her ikisinin de `false` olduğundan emin olun.

### Sürekli Önbellek Temizleyen Eklentiler

Bazı eklentiler `wp_cache_flush()` çağrısını çok agresif yapar. Her temizlemede her şeyin veritabanından yeniden oluşturulması gerekir. İsabet oranınız şüpheli derecede düşükse, büyük olasılıkla budur. Redis komutlarını izleyerek suçluyu yakalayabilirsiniz: `redis-cli MONITOR | grep FLUSHDB`

### Transient Davranış Değişiklikleri

Kalıcı bir object cache yüklediğinizde, WordPress transient'leri artık veritabanında değil object cache'te saklar. Bu genellikle iyidir (daha az veritabanı şişkinliği), ancak transient'ler artık önbellek çıkarmasına tabidir. Transient'lerin günlerce kalmasına bağımlı eklentileriniz varsa, Redis bellek baskısı altında bunları çıkardığında bozulabilirler.

### Serileştirme Yükü

WordPress her nesneyi önbelleğe almadan önce serileştirir. 500 yazılık karmaşık bir WP_Query sonucu gibi büyük nesneler için serileştirme/serileştirme çözme maliyeti, sorguyu tekrar çalıştırmaktan daha yüksek olabilir. Nadir, ancak özel veri önbelleğe alıyorsanız bilmenizde fayda var.

## "Hiçbir Şey Yapma" Seçeneği

**Bazen en iyi object cache, hiç kalıcı object cache olmamaktır.**

Varsayılan WordPress object cache her istek içinde çalışmaya devam eder. Siteniz çoğunlukla anonim ziyaretçilerden oluşuyor ve bir sayfa önbelleği isteklerin %95'ini karşılıyorsa, Redis karmaşıklığı eklemeye değmeyebilir. Sayfa önbelleğini atlayan sayfalar (yönetim paneli, AJAX, WP-Cron) yığınınıza başka bir hizmet eklemeyi haklı kılacak kadar veritabanı yükü oluşturmayabilir.

Gerçek veritabanı sorgu sayınıza ve yükünüze bakarak başlayın. Sayfa başına 50-80 sorgu görüyorsanız ve veritabanı sunucunuz zorlanmıyorsa, Redis'e hiç ihtiyacınız olmayabilir. Önce veritabanınızı optimize etmeye odaklanın — şişmiş tabloları temizleyin, eksik indeksleri düzeltin, otomatik yüklenen veriyi azaltın.

Object cache bir araçtır, bir gereklilik değil. Veriler gerekli olduğunu gösterdiğinde kullanın.