Redis'ten Valkey'e Geçiş ve WordPress Optimizasyonu

10 Nisan 2026 11 dk okuma 60 okunmaAlper Peri

Redis'ten Valkey'e Geçiş ve WordPress Optimizasyonu

Bu rehberin ilk versiyonunu Nisan 2026'da yayınlamıştım. O günden beri Valkey 8.0'dan 9.1'e güncellendi, çeşitli kritik güvenlik yamaları aldı ve kurulum aşamasında bizzat tecrübe ettiğim bazı yeni ince ayarlar ortaya çıktı. Özellikle systemd entegrasyonu ve çok çekirdekli io-threads kullanımı konusunda edindiğim deneyimlerle yazıyı baştan sona güncelledim. Aşağıdaki komutların tamamını kendi canlı sunucumda aktif olarak kullanıyorum; gönül rahatlığıyla kopyalayıp yapıştırabilirsiniz.

İlk yayın: 10 Nisan 2026 · Son güncelleme: 2 Eylül 2026

İçindekiler

  1. Valkey Nedir?
  2. Neden Redis Yerine Valkey?
  3. Kurulum Öncesi Kritik Karar: Veriler Kalıcı mı, Sadece Cache mi?
  4. Adım Adım Kurulum (Ubuntu 22.04)
  5. LiteSpeed ve PHP Bağlantısı
  6. PageSpeed: LSCache Dokunuşları
  7. Güvenlik: 9.1.x Sürümlerini Yakından Takip Edin
  8. Güncelleme ve Geri Dönüş
  9. Sonuç: Sunucu Yükü ve Hız Deneyimi

Valkey Nedir?

Valkey, açık kaynak kodlu (BSD lisanslı) ve oldukça yüksek performanslı bir bellek içi (in-memory) veri deposudur. Hatırlarsınız, Redis 2024 yılında lisans modelini değiştirip açık kaynak yapısından uzaklaşmıştı. Bunun üzerine Linux Foundation devreye girdi ve Redis 7.2.4'ün son özgür sürümünü çatallayarak (fork) Valkey projesini başlattı.

Verileri diske yazmak yerine doğrudan RAM üzerinde işlediği için inanılmaz düşük gecikme süreleri sunuyor. Bu da onu önbellekleme (cache), oturum yönetimi veya arka plan kuyruk işlemleri için kusursuz bir teknoloji haline getiriyor. İşin en güzel tarafı ise şu: Valkey, veri yapısı ve iletişim protokolü düzeyinde Redis ile tamamen uyumlu. Klasik string, list veya hash yapıları aynen duruyor. Yani sisteminizde halihazırda kurulu olan Redis eklentileri (örneğin WordPress "Redis Object Cache", LiteSpeed Cache veya phpredis), arka planda Valkey çalıştığını fark etmeden, tek bir kod değişikliğine gerek duymadan çalışmaya devam ediyor.

Küçük Bir Not

Redis, 2025 yılında çıkardığı Redis 8 sürümüyle AGPLv3 lisans seçeneğini geri getirdi. Yani "Redis tamamen kapalı kaynak oldu" söylemi artık pek doğru değil. Ancak bu süreçte Valkey, teknik anlamda ciddi bir gelişim gösterdi. Çok çekirdekli komut işleme (io-threads) desteği, çok daha verimli bellek yönetimi ve hızla yayınlanan güvenlik yamalarıyla öne çıktı. Kısacası, benim Valkey'i tercih etme sebebim artık sadece lisans özgürlüğü değil, sunduğu bu güçlü mühendislik vizyonudur.

Neden Redis Yerine Valkey?

Sistemlerimde bu geçişi yapmamı sağlayan temel motivasyonlar şunlardı:

  1. Yüzde Yüz Uyumluluk: Mevcut WordPress "Redis Object Cache" ve LiteSpeed Cache eklentilerim hiçbir ayar değiştirmeden doğrudan çalışıyor. Sistem 127.0.0.1:6379 adresiyle iletişim kurmaya olduğu gibi devam ediyor.
  2. Çok Çekirdekli Performans (Throughput): io-threads özelliği sayesinde ağ trafiği ve komut işleme yükü birden fazla işlemci çekirdeğine dağıtılabiliyor. Tek çekirdeğe sıkışıp darboğaz yaratan klasik Redis'e kıyasla, yüksek trafikli anlarda aradaki fark gerçekten muazzam.
  3. Düşük Gecikme ve Mükemmel TTFB: Veritabanı sorguları diske inmeden doğrudan RAM'den milisaniyeler içinde yanıtlandığı için sitenin ilk baytı alma süresi (TTFB) gözle görülür oranda iyileşiyor.
  4. Güncel Güvenlik Yamaları: 9.1.x serisi oldukça agresif ve hızlı bir güvenlik güncelleme döngüsüne sahip. Sistemi kaynaktan derlediğimizde bu yamaları bekletmeden, tek bir komutla sunucuya alabiliyoruz.

Kurulum Öncesi Kritik Karar: Veriler Kalıcı mı Olacak, Yoksa Sadece Cache mi?

Komut satırına geçmeden önce ihtiyacımızı netleştirmemiz gerekiyor: Valkey'i tam olarak ne amaçla kullanacağız?

WordPress nesne önbellekleme (object cache) ve LiteSpeed senaryosunda Valkey'i saf bir önbellek (cache) olarak konumlandırıyoruz. Yani içindeki veriler silinse bile veritabanından kolayca tekrar oluşturulabilecek geçici verilerdir. Bu nedenle:

  • Disk kalıcılığını (persistence) tamamen kapatıyoruz: Konfigürasyonda save "" ve appendonly no parametrelerini kullanacağız.
  • Peki avantajı ne? Sunucuyu gereksiz disk okuma ve yazma (I/O) yükünden kurtarıyoruz. fork() işlemleri sırasında yaşanan anlık bellek şişmelerini ve versiyon yükseltmelerindeki RDB/AOF format uyumsuzluklarını çöpe atıyoruz. Sunucuyu yeniden başlattığınızda cache sıfırlanır, ancak WordPress birkaç dakika içinde en taze verilerle burayı yeniden doldurur. Ortada "kalıcı" olması gereken bir veri olmadığı için veri kaybı riskimiz de sıfırdır.
  • Tahliye (Eviction) Politikası: maxmemory-policy allkeys-lfu ayarını tercih ediyoruz. LRU (en son kullanılan) yerine LFU (en az sıklıkla kullanılan) mantığıyla çalışarak; RAM dolduğunda Valkey "en az sıklıkla okunan" verileri silip, en popüler ve sık ziyaret edilen sayfalarınızı RAM'de tutmaya devam ediyor.

Eğer Valkey'i e-ticaret sepet verileri, kullanıcı oturumları (session) veya kritik arkaplan kuyrukları gibi asla kaybolmaması gereken veriler için kullanacaksanız, bu rehberdeki optimizasyonlar size uygun değildir. O senaryoda appendonly yes ve doğru bir appendfsync yapılandırması kullanmanız gerekir. Biz bu rehberde performans odaklı saf cache senaryosuyla yola devam ediyoruz.

Adım Adım Kurulum (Ubuntu 22.04)

Valkey henüz standart Ubuntu repolarına girmiş değil. Bu yüzden şimdilik en temiz ve sorunsuz yol sistemi doğrudan kaynaktan derlemek. Ancak klasik yöntem olan "tar.gz indirip açmak" yerine doğrudan Git deposunu kullanacağız. Neden mi? Çünkü yeni bir sürüm çıktığında güncellemek sadece git fetch ve git checkout komutlarını çalıştırmak kadar basit bir rutine dönüşecek.

1. Bağımlılıklar ve mevcut Redis'i durdurma

systemctl stop redis-server 2>/dev/null || true

apt update
apt install -y build-essential tcl pkg-config wget git libsystemd-dev

libsystemd-dev paketi burada çok kritik. Bir sonraki adımda USE_SYSTEMD=yes parametresiyle derleme yapacağız ve bu paket sistemde yoksa derleyici systemd desteğini sessizce atlayacaktır.

2. Kaynağı git ile alma

cd /opt
git clone https://github.com/valkey-io/valkey.git valkey-git
cd valkey-git

# En son kararlı 9.x etiketini bul ve ona geç
git checkout "$(git tag | grep -E '^9\.[0-9]+\.[0-9]+$' | sort -V | tail -1)"
git describe --tags   # -> 9.1.2 (yazının yazıldığı andaki güncel sürüm)

Sorun giderme

Bazı sunucularda git clone HTTPS üzerinden bağlanırken could not read Username for 'https://github.com' ya da expected flush after ref listing hatası verir. Bu, git'in HTTP/2 protokolü anlaşmasıyla ilgili bir sorundur (curl etkilenmez). Çözümü basit: tüm git komutlarını git -c http.version=HTTP/1.1 … şeklinde çağırın.

3. Derleme — USE_SYSTEMD=yes ile

make -j"$(nproc)" USE_SYSTEMD=yes
make install          # /usr/local/bin/ altına kurar

# Doğrula: Dosya gerçekten libsystemd'ye linklenmiş mi?
ldd src/valkey-server | grep libsystemd

Neden USE_SYSTEMD=yes kullanıyoruz? Servis dosyasında Type=notify ayarını kullanacağız. Bu modda Valkey, sistemin hazır olduğunu belirten "hazırım" sinyalini (sd_notify) systemd'ye bizzat kendisi iletir. systemd de servisi ancak Valkey gerçekten bağlantı kabul etmeye başladığında "active" olarak işaretler. Eğer bu parametreyi vermeden düz derleme yaparsak bu iletişim kurulamaz ve sunucu loglarınız systemd supervision error: NOTIFY_SOCKET not found! hatalarıyla dolup taşar.

4. Kısıtlı kullanıcı ve dizinler

useradd -r -s /bin/false valkey 2>/dev/null || true
mkdir -p /var/lib/valkey /etc/valkey
chown valkey:valkey /var/lib/valkey
chmod 770 /var/lib/valkey

5. Yapılandırma dosyası — /etc/valkey/valkey.conf

Aşağıdaki kod bloğunu kopyalayıp doğrudan terminalinize yapıştırabilirsiniz. EOF etiketini tek tırnak içinde kullandığımız için, bash kabuğu (shell) içeriğe müdahale etmeyecek ve dosyayı tırnak hataları olmadan güvenle oluşturacaktır:

cat > /etc/valkey/valkey.conf <<'EOF'
bind 127.0.0.1
port 6379
daemonize no
supervised systemd
dir /var/lib/valkey

# --- Cache profili ---
maxmemory 512mb
maxmemory-policy allkeys-lfu
save ""
appendonly no

# --- Cok cekirdekli isleme ---
# Cekirdek sayisinin yarisi iyi bir baslangic (2-4). Tek/cift cekirdekli
# VPS'te bu satiri silin (varsayilan: kapali).
io-threads 4
EOF

Buradaki iki ayar oldukça kritik:

  • maxmemory 512mb — Bu değeri sunucunuzun boş RAM kapasitesine göre ayarlamalısınız. Genel kural olarak boştaki RAM'in %25 ile %40'ı arası idealdir. Eğer sunucu metriklerinizde used_memory değerinin sürekli limitlere dayandığını ve evicted_keys (silinen anahtarlar) oranının hızla arttığını görürseniz bu değeri biraz daha yukarı çekebilirsiniz.
  • maxmemory-policy allkeys-lfu — WordPress mimarisi için en iyi performansı veren seçenektir. Yukarıda da bahsettiğim gibi "en son" kullanılanı değil, "en az sıklıkla" kullanılan veriyi bellekten atar.

6. Servis dosyası — /etc/systemd/system/valkey.service

cat > /etc/systemd/system/valkey.service <<'EOF'
[Unit]
Description=Valkey In-Memory Data Store
After=network.target

[Service]
Type=notify
TimeoutStartSec=60
TimeoutStopSec=30
User=valkey
Group=valkey
ExecStart=/usr/local/bin/valkey-server /etc/valkey/valkey.conf
ExecStop=/usr/local/bin/valkey-cli shutdown
Restart=always
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF

7. Kernel parametresi: vm.overcommit_memory

Valkey'i başlatırken loglarda sıkça karşılaşılan o meşhur "Memory overcommit must be enabled!" uyarısını çoğu kişi es geçer. Bizim saf cache senaryomuzda bu durumun performansa devasa bir olumsuz etkisi olmasa da, tek satırlık bir komutla hem bu uyarıdan kökten kurtuluyor hem de sunucu loglarımızı tertemiz tutuyoruz:

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

8. Servisi tanıtma ve başlatma

systemctl daemon-reload
systemctl enable valkey
systemctl start valkey

9. Doğrulama

valkey-cli ping                                   # -> PONG
valkey-server --version                           # -> v=9.1.2 ...
valkey-cli INFO server | grep -E 'valkey_version|redis_version'
systemctl show valkey -p Type -p ActiveState      # Type=notify / active

# En onemlisi: log temiz mi?
journalctl -u valkey -n 20 -o cat | grep -iE 'warn|error|not found' \
  && echo ">>> incele" || echo ">>> temiz"

Çıktıda redis_version:7.2.4 gibi bir ibare görürseniz paniğe kapılmayın. Bu durum gayet normal; Valkey geriye dönük uyumluluğu korumak için kendisini Redis istemcilerine bu şekilde tanıtmaya devam ediyor. Gerçek sürüm numaramızı hemen altındaki valkey_version satırında görebilirsiniz.

LiteSpeed ve PHP Bağlantısı

PHP tarafında phpredis eklentisi her lsphp sürümüyle birlikte gelir (lsphpXX-redis). CyberPanel bunu genellikle hazır kurar. Kontrol etmek isterseniz:

/usr/local/lsws/lsphp83/bin/php -m | grep -i redis

Ardından LiteSpeed'in yeni motoru tanıması için servisi yeniden başlatıyoruz:

systemctl restart lsws
# veya kesintisiz restart için:
/usr/local/lsws/bin/lswsctrl restart

Daha önce de belirttiğim gibi, WordPress tarafında en ufak bir değişiklik yapmamıza gerek yok. "Redis Object Cache" eklentiniz yine eski alışkanlığıyla 127.0.0.1:6379 portuna bağlanmaya çalışacak, sadece artık kapıyı Redis yerine Valkey açacak. Tek yapmanız gereken, WordPress panelinizden Settings → Redis menüsüne girip "Enable Object Cache" butonuna tıklamak. Ekranda "Connected" ibaresini gördüyseniz işlem başarıyla tamamlanmış demektir.

PageSpeed: LSCache Dokunuşları

Sadece sunucu altyapısını hızlandırmak işin mutfak kısmıydı. Ön yüzde de ziyaretçiye ve arama motorlarına bu hızı hissettirmemiz gerekiyor. Kendi sitemde PageSpeed Insights mobil puanımı 37'lerden alıp 90'ların üzerine çıkaran o kritik LSCache ayarlarını aşağıda paylaşıyorum:

Oluşturmayı Engelleyen (Render-blocking) İstekleri Temizleyin

  • CSS/JS Birleştirme (Combine): KAPALI. Artık HTTP/2 ve HTTP/3 protokollerini kullanıyoruz. Bu modern altyapılarda dosyaları devasa tek bir paket haline getirmek performansa faydadan çok zarar veriyor. Tarayıcı zaten küçük dosyaları eşzamanlı olarak çok daha hızlı ve verimli indirebiliyor.
  • JS Load Deferred / Delayed: Tarayıcının sayfa oluşturma (render) işlemini kilitlememesi için JavaScript dosyalarını erteleyin. "Delayed" (Gecikmeli) seçeneği çok agresiftir ve bazen sitenizdeki işlevleri veya temayı bozabilir. Bu yüzden işe önce daha güvenli olan "Deferred" (Ertelenmiş) ayarıyla başlayıp sitenizi test etmenizi öneririm.
  • CSS: Load Asynchronous + Critical CSS oluşturma açık olmalı.

LCP Görselini Koruyun

  • Sayfanın en üstünde yer alan ana görsel (LCP image) asla lazy-load işlemine sokulmamalıdır. Bu kritik görselin yolunu (URL'sini) LSCache → Media → "Lazy Load Image Excludes" listesine mutlaka ekleyin. Böylece tarayıcı siteyi açtığı ilk saniyede doğrudan bu görseli yükleyebilsin.

Nesne Önbelleği (Object Cache)

  • LSCache → Object sekmesine gidin. Tür olarak Redis seçin, host alanına 127.0.0.1, port alanına ise 6379 yazın. Ardından Object Cache ve Persistent Connection seçeneklerini aktif hale getirin. Buradaki menüde "Valkey" diye ayrı bir isim görmeyeceksiniz; Redis seçeneği arka planda Valkey ile sorunsuz bir şekilde konuşacaktır.

LSCache ayarları — Combine kapalı, JS Deferred, Object Cache: Redis

Güvenlik: 9.1.x Sürümlerini Yakından Takip Edin

Valkey 9.1 serisi kısa aralıklarla çok önemli güvenlik sürümleri yayınladı. Örneğin:

  • 9.1.1 — TLS bağlantı yönetiminde CLIENT KILL üzerinden uzaktan kod çalıştırmaya (RCE) kadar varabilen use-after-free zafiyeti ve bozuk stream RDB dosyalarıyla ilgili RCE açığı kapatıldı.
  • 9.1.2 — Lua yorumlayıcı tarafında kimlik doğrulamasını aşabilen use-after-free açığı; GEORADIUS, HGETEX, MOVE ve COPY komutlarında karşılaşılan ACL bypass sorunları ile io-threads açıkken pipeline komutlarında yaşanan panic durumları düzeltildi.

Sisteminiz dışarıya tamamen kapalı olsa (bind 127.0.0.1) ve yerel ağda şifresiz çalışsa dahi, özellikle io-threads aktifleştirdiyseniz bu yamalar sunucu sağlığı için kritik önem taşıyor. Açık kaynak dünyasında güvenlik güncellemelerini asla ertelemeyin.

Güncelleme ve Geri Dönüş

Git deposu üzerinden kurulum yaptığımız için sürüm yükseltme süreci oldukça rahat ve tekrar edilebilir bir yapıya kavuştu. Güncellemeler için kullanabileceğiniz şablon bir betik (script):

#!/bin/bash
set -euo pipefail
REPO=/opt/valkey-git
BK="/opt/valkey-yedek-$(date +%F_%H%M%S)"

# 1) Eski binary'leri yedekle
mkdir -p "$BK"
cp -a /usr/local/bin/valkey-server /usr/local/bin/valkey-cli \
      /usr/local/bin/valkey-benchmark "$BK/"
cp -a /etc/valkey/valkey.conf /etc/systemd/system/valkey.service "$BK/"

# 2) Yeni surumu al ve derle
cd "$REPO"
git fetch --tags --force
git checkout "$(git tag | grep -E '^9\.[0-9]+\.[0-9]+$' | sort -V | tail -1)"
make distclean
make -j"$(nproc)" USE_SYSTEMD=yes
ldd src/valkey-server | grep -q libsystemd || { echo 'libsystemd linki yok'; exit 1; }

# 3) Gecici portta hizli test
./src/valkey-server --port 7899 --daemonize no --save '' --appendonly no --dir /tmp &
TP=$!; sleep 1
[ "$(./src/valkey-cli -p 7899 ping)" = 'PONG' ] || { kill "$TP"; exit 1; }
./src/valkey-cli -p 7899 shutdown nosave 2>/dev/null || true

# 4) Degistir
systemctl stop valkey
install -m0755 src/valkey-server src/valkey-cli src/valkey-benchmark /usr/local/bin/
systemctl start valkey
sleep 2

# 5) Dogrula
valkey-cli ping
valkey-cli INFO server | grep valkey_version
journalctl -u valkey -n 15 -o cat | grep -iE 'warn|error' && echo 'INCELE' || echo 'TEMIZ'
echo "Geri donus:  cp $BK/valkey-* /usr/local/bin/ && systemctl restart valkey"

İşler yolunda gitmezse endişelenmeyin; geri dönüş işlemi gerçekten tek satırlık bir komuta bakıyor. Aldığımız yedeği eski yerine geri kopyalayıp servisi yeniden başlatmak yeterli. Ortada kalıcı bir verimiz olmadığı için veri kurtarma, taşıma veya zorlu migrasyon süreçleriyle uğraşmıyoruz.

Sonuç: Sunucu Yükü ve Hız Deneyimi

Valkey geçişinden sonra sunucuda top -c komutuyla yaptığım canlı gözlemlerde, lsphp süreçlerinin işlemciyi eskisine nazaran belirgin şekilde daha az meşgul ettiğini gördüm. Sorgular doğrudan RAM üzerinden yanıtlandığı için iowait değerleri çok daha stabil bir hale geldi; io-threads mimarisi sayesinde de trafik yoğunlaştığında sistemin tek bir çekirdeğe kilitlenmesi sorununu tamamen aştım. PageSpeed tarafında ise yukarıdaki LSCache dokunuşlarıyla birlikte mobil performans puanım 37'lerden 90'ların üzerine çıktı.

Sonuç olarak; eğer siz de bir CyberPanel ve OpenLiteSpeed kullanıcısıysanız, Git üzerinden kendi derlediğiniz, USE_SYSTEMD=yes ile sisteme pürüzsüz entegre olmuş, io-threads ile çok çekirdeğin gücünü kullanan ve kalıcılığı tamamen kapatılmış saf bir Valkey mimarisi kurmak, sunucunuzu gerçekten bambaşka bir seviyeye taşıyor. İşin zor kısmı sadece bu ilk kurulumu yapmak, sonrasında güncellemeleri yönetmek hazırladığımız betik sayesinde sadece saniyelerinizi alacak.

Başka bir yazıda görüşmek üzere, sağlıklı ve mutlu günler diliyorum.

Kod kopyalandı
#CyberPanel Performans Rehberi: Redis’ten Valkey’e Geçiş#Valkey#Valkey kurulumu#Redis yerine valkey
Alper Peri

Alper Peri

Full Stack Developer & Linux SysAdmin

Birlikte çalışalım

Yorumlar (0)

$ henüz yorum yok — ilk yorumu sen yaz.

Yorum yaz

Yorumlar onaylandıktan sonra yayınlanır. E-posta adresiniz sitede gösterilmez, yalnızca gerekirse size ulaşmak için kullanılır. Ayrıntılar: Gizlilik Politikası.

#İlgili Yazılar

En Güvenli Hosting Kontrol Panelleri 2025
aaPanelCentos Web Panel

En Güvenli Hosting Kontrol Panelleri 2025

Sunucu yönetimi konusunda en kritik unsurlardan biri güvenliktir . Kontrol paneli, sadece bir yönetim arayüzü olmaktan çok daha fazlasıdır; sunucunun…

8 Mayıs 2025 6 dk okuma 184 okunma
Neden cyberpanel kullanmamalısınız
CyberPanelGüvenlik

Neden CyberPanel Kullanmamalısınız?

CyberPanel, ilk bakışta cazip özellikleriyle dikkat çekse de, gerçek kullanıcı deneyimleri ve teknik detaylar incelendiğinde ciddi sorunlar…

7 Mart 2025 2 dk okuma 3 okunma
Cyberpanel yüklü 22.000 den fazla sunucu hacklendi
CyberPanelGüvenlik

Cyberpanel kullanan 22.000 sunucu hacklendi

22.000’den fazla CyberPanel sunucusunu etkileyen kritik bir uzaktan kod çalıştırma (RCE) açığı, PSAUX fidye yazılımı saldırısı ile bütünleştirilerek…

29 Ekim 2024 2 dk okuma 26 okunma