WordPress dışarıdan bakınca basit bir yayın sistemi gibi görünse de, arka planda her sayfa açılışında şaşırtıcı sayıda veritabanı sorgusu çalıştırır. Ana sayfayı bir kez açtığınızda WordPress; site ayarlarını, aktif temayı, kayıtlı eklentileri, menüleri, widget'ları ve gösterilecek yazıları ayrı ayrı sorgularla veritabanından çeker. Bu sorguların büyük kısmı her ziyaretçide neredeyse birebir aynıdır; yani sistem, değişmeyen aynı bilgiyi saniyede belki yüzlerce kez veritabanından yeniden istemektedir. İşte bu gereksiz tekrar, dinamik sayfaların en görünmez ama en gerçek yavaşlık kaynağıdır.
Redis object cache tam olarak bu tekrarı ortadan kaldırmak için vardır. Sık istenen ve az değişen sorgu sonuçlarını sunucunun belleğinde tutar; WordPress bir sonraki istekte aynı veriyi MySQL'e gitmeden doğrudan bellekten okur. Bu yazıda object cache'in ne işe yaradığını, sayfa önbelleğinden neden farklı olduğunu, sunucunuzda Redis'in gerçekten çalışıp çalışmadığını nasıl doğrulayacağınızı, Redis Object Cache eklentisinin kurulumunu ve wp-config.php üzerindeki kritik Redis ayarlarını gerçek komutlarla adım adım göstereceğiz. Sonunda önbelleğin gerçekten devrede olup olmadığını nasıl teyit edeceğinizi de öğreneceksiniz.
Object Cache Nedir ve Neyi Hızlandırır#
Object cache (nesne önbelleği), bir uygulamanın tekrar tekrar ürettiği veri parçalarını bellekte saklayan bir katmandır. WordPress bağlamında bu "veri parçaları" çoğunlukla veritabanı sorgularının sonuçlarıdır: bir seçeneğin değeri, bir kullanıcının bilgileri, bir yazının meta alanları, aktif eklentilerin listesi gibi. WordPress bu verileri her istekte yeniden hesaplamak yerine, bir kez çekip önbelleğe koyar ve sonraki isteklerde oradan okur. Böylece MySQL'e giden sorgu sayısı ciddi biçimde azalır.
WordPress'in aslında yerleşik bir nesne önbelleği vardır, ancak varsayılan hali "kalıcı değildir". Yani önbelleğe alınan veriler yalnızca o tek istek boyunca bellekte tutulur ve istek bitince silinir. Bir sonraki ziyaretçi geldiğinde her şey sıfırdan başlar. Redis devreye girdiğinde bu önbellek "kalıcı" hale gelir: bir istekte hesaplanan sonuç, dakikalarca hatta saatlerce bellekte kalır ve tüm ziyaretçiler ondan faydalanır. Buna teknik olarak persistent object cache (kalıcı nesne önbelleği) denir.
Peki bu neyi hızlandırır? Object cache özellikle dinamik sayfaları hızlandırır. Giriş yapmış kullanıcılar, sepet gösteren WooCommerce mağazaları, üyelik siteleri, forum benzeri sürekli değişen içerikler; bunların hepsi tam sayfa önbelleğinden yeterince faydalanamaz çünkü her kullanıcı için sayfa farklıdır. İşte object cache bu noktada parlar: sayfanın kendisi kişiye özel üretilse bile, o sayfayı üretirken kullanılan ortak sorguların (ayarlar, menüler, ürün bilgileri) sonuçları önbellekten gelir. Redis'in bellek içi mimarisinin neden bu kadar hızlı olduğunu daha derinlemesine anlamak isterseniz Redis nedir rehberimize göz atabilirsiniz.
Sayfa Önbelleği ile Nesne Önbelleği Arasındaki Fark#
WordPress hızlandırma konusunda en sık karıştırılan iki kavram sayfa önbelleği ile nesne önbelleğidir. İkisi de "önbellek" kelimesini taşır ama tamamen farklı katmanlarda çalışır ve birbirinin yerine geçmez; en iyi sonucu birlikte kullanıldıklarında verirler.
Sayfa önbelleği (page cache), WordPress'in ürettiği tam HTML çıktısını olduğu gibi saklar. Bir ziyaretçi ana sayfayı ilk açtığında WordPress bütün işi yapıp HTML üretir, sayfa önbelleği bu HTML'i diske ya da belleğe kaydeder. Sonraki ziyaretçilere WordPress hiç çalıştırılmadan bu hazır HTML sunulur. Son derece hızlıdır ama bir kısıtı vardır: kişiye özel değişen sayfalarda (giriş yapmış kullanıcı, dolu sepet, kişisel panel) kullanılamaz, çünkü herkese aynı çıktıyı vermek yanlış olur.
Nesne önbelleği (object cache) ise HTML'i değil, o HTML üretilirken kullanılan ham verileri saklar. Sayfa her istekte yeniden üretilse bile, üretim sırasında ihtiyaç duyulan sorgular önbellekten geldiği için işlem çok daha hızlı biter. Bu yüzden object cache, sayfa önbelleğinin işe yaramadığı dinamik senaryolarda hayat kurtarır. Aradaki farkı şöyle özetleyebiliriz:
| Özellik | Sayfa Önbelleği | Nesne Önbelleği (Redis) |
|---|---|---|
| Ne saklar? | Hazır HTML çıktısı | Veritabanı sorgu sonuçları |
| WordPress çalışır mı? | Hayır, HTML doğrudan sunulur | Evet, ama daha az sorgu ile |
| Dinamik sayfalar | Genellikle atlanır | Tam olarak hızlanır |
| Giriş yapmış kullanıcı | Faydalanamaz | Faydalanır |
| Tipik araç | LiteSpeed Cache, WP Rocket | Redis Object Cache |
Kısacası ikisi rakip değil, tamamlayıcıdır. Sayfa önbelleği ziyaretçilerin gördüğü anonim sayfaları uçurur; nesne önbelleği ise yönetim paneli, WooCommerce ödeme adımları ve giriş yapmış kullanıcı deneyimini akıcı hale getirir. WordPress hızını bütünsel olarak nasıl ele alacağınıza dair WordPress hız optimizasyonu rehberimizde bu katmanların tamamına değiniyoruz.
Sunucuda Redis Çalışıyor mu, Nasıl Doğrulanır#
Object cache eklentisi kurmadan önce yapılması gereken ilk iş, sunucuda Redis servisinin gerçekten kurulu ve çalışır durumda olduğunu doğrulamaktır. Eklentiyi kurup Redis olmayan bir sunucuda "connected" beklemek, en sık yapılan hatadır. SSH erişiminiz varsa doğrulama birkaç saniye sürer. Önce servis durumuna bakın:
sudo systemctl status redis-server
Çıktıda active (running) ifadesini görüyorsanız servis ayaktadır. Servisin gerçekten yanıt verdiğini test etmenin en kesin yolu ise komut satırı istemcisiyle bir ping göndermektir:
redis-cli ping
# Beklenen yanıt: PONG
PONG yanıtını aldıysanız Redis çalışıyor ve bağlantı kabul ediyor demektir. Eğer Redis kurulu değilse, bir Ubuntu/Debian sunucusunda kurulumu tek komutla yapabilirsiniz:
sudo apt update
sudo apt install redis-server -y
sudo systemctl enable --now redis-server
Redis'in hangi adres ve portta dinlediğini de bilmeniz gerekir çünkü bu değerleri birazdan wp-config.php içine yazacağız. Varsayılan olarak Redis, yalnızca aynı sunucudan erişilebilecek şekilde 127.0.0.1 adresinde ve 6379 portunda çalışır. Bunu doğrulamak için yapılandırma dosyasındaki ilgili satırlara bakın:
grep -E "^bind|^port|^requirepass" /etc/redis/redis.conf
Buradaki bind 127.0.0.1 satırı Redis'in yalnızca yerel bağlantı kabul ettiğini, yani güvenli konumda olduğunu gösterir. Paylaşımlı ya da yönetilen bir hosting kullanıyorsanız Redis genellikle sunucu tarafında hazır kurulu gelir ve SSH ile uğraşmanıza gerek kalmaz; bu durumda doğrudan eklenti adımına geçebilirsiniz. Redis kurulu bir altyapıyı sıfırdan uğraşmadan kullanmak isterseniz WordPress hosting paketlerimiz bu bileşeni hazır sunar. Tam kontrol isteyenler ise VDS sunucu üzerinde Redis'i istedikleri gibi yapılandırabilir.
PHP Redis Eklentisinin Kurulması#
WordPress'in Redis ile konuşabilmesi için PHP tarafında bir köprüye ihtiyaç vardır. Bu köprü, phpredis olarak da bilinen PHP Redis eklentisidir. Redis servisi çalışsa bile bu PHP eklentisi yüklü değilse, WordPress önbelleğe bağlanamaz ve eklenti panelinde "Redis erişilebilir değil" benzeri bir uyarı görürsünüz. Bu yüzden servisi doğruladıktan sonra ikinci adım PHP eklentisini kurmaktır.
Kullandığınız PHP sürümüne uygun paketi kurmanız önemlidir. Örneğin sunucunuz PHP 8.2 kullanıyorsa:
sudo apt install php-redis -y
sudo systemctl restart php8.2-fpm
Kurulumdan sonra PHP-FPM servisini yeniden başlatmak şarttır; aksi halde çalışan PHP süreçleri yeni eklentiyi tanımaz. Eklentinin gerçekten yüklendiğini komut satırından hızlıca doğrulayabilirsiniz:
php -m | grep -i redis
# Çıktıda "redis" görünmeli
Burada dikkat edilmesi gereken bir incelik var: komut satırındaki (CLI) PHP sürümü ile web sitesini çalıştıran PHP-FPM sürümü farklı olabilir. En güvenilir doğrulama, siteyi gerçekte çalıştıran sürümde eklentinin görünmesidir. cPanel kullanıyorsanız bu işi arayüzden de yapabilirsiniz: Select PHP Version (ya da MultiPHP Manager / PHP eklenti yöneticisi) ekranını açıp redis (veya phpredis) kutusunu işaretlemeniz yeterlidir. Panel gerekli PHP-FPM yenilemesini kendisi yapar. PHP sürümünüzü nasıl kontrol edip değiştireceğinizi bilmiyorsanız, web hosting planlarımızın sunduğu cPanel arayüzü bu adımı birkaç tıkla halleder.
Bu noktada iki temel bileşen de hazır olmalı: sunucuda çalışan bir Redis servisi ve onunla konuşabilen bir PHP Redis eklentisi. Bu ikisi olmadan hiçbir WordPress eklentisi object cache'i devreye alamaz; bu yüzden eklentiye geçmeden önce her ikisini de teyit etmek, sonradan yaşanacak "neden bağlanmıyor" sorununun büyük kısmını baştan önler.
Redis Object Cache Eklentisinin Kurulumu#
Sunucu tarafı hazır olduğunda WordPress tarafı oldukça basittir. WordPress'in Redis'i kullanabilmesi için bir "drop-in" dosyasına ihtiyaç vardır ve en pratik yol, bunu sizin için oluşturan bir eklenti kullanmaktır. En yaygın ve güvenilir tercih, adı doğrudan işini anlatan Redis Object Cache eklentisidir. Kurulumu şu adımlarla yapılır:
- WordPress yönetim paneline girin ve Eklentiler > Yeni Ekle ekranını açın.
- Arama kutusuna Redis Object Cache yazın ve listede çıkan (geliştiricisi "Till Krüss" olan) eklentiyi kurun.
- Eklentiyi Etkinleştirin. Ardından sol menüde Ayarlar > Redis bölümü belirir.
- Redis ayarları ekranını açın ve Enable Object Cache (Nesne Önbelleğini Etkinleştir) düğmesine tıklayın.
Bu düğmeye bastığınızda eklenti, wp-content dizinine object-cache.php adında bir drop-in dosyası yazar. Bu dosya WordPress'in yerleşik önbellek sistemini devralır ve tüm önbellek okuma/yazma işlemlerini Redis'e yönlendirir. Her şey doğruysa aynı ekranda durumun Connected (Bağlı) olduğunu gösteren yeşil bir gösterge görürsünüz. Bu, WordPress'in Redis'e başarıyla bağlandığı ve nesne önbelleğinin artık kalıcı olduğu anlamına gelir.
Eğer durum "Not connected" ya da "Redis erişilebilir değil" gösteriyorsa panik yapmayın; sorun neredeyse her zaman şu üç şeyden biridir: Redis servisi çalışmıyordur, PHP Redis eklentisi yüklü değildir, ya da bağlantı adresi/portu yanlıştır. İlk ikisini önceki adımlarda doğruladıysanız, geriye kalan bağlantı ayarlarını wp-config.php üzerinden netleştirmek gerekir. Bir sonraki bölüm tam olarak bunu ele alıyor.
wp-config.php Redis Ayarları#
Redis Object Cache eklentisi, ayarları wp-config.php dosyasındaki sabitlerden (constant) okur. Eklenti hiçbir tanım bulamazsa varsayılan olarak 127.0.0.1:6379 adresine, parolasız ve 0 numaralı veritabanına bağlanmayı dener. Çoğu tek siteli kurulumda bu varsayılanlar yeterlidir; ancak Redis'e parola tanımladıysanız, farklı bir port kullanıyorsanız ya da aynı Redis sunucusunu birden fazla site paylaşıyorsa, ayarları elle vermeniz gerekir.
wp-config.php dosyasını açın ve /* That's all, stop editing! */ satırının üstüne aşağıdaki tanımları ekleyin. Bu, kurulumların büyük çoğunluğu için yeterli olan temel bir yapılandırmadır:
// Redis bağlantı bilgileri
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
// Redis'e parola tanımladıysanız açın:
// define( 'WP_REDIS_PASSWORD', 'redis-parolaniz' );
Buradaki WP_REDIS_HOST ve WP_REDIS_PORT değerlerinin, daha önce redis.conf içinde gördüğünüz bind ve port değerleriyle birebir aynı olması gerekir. WP_REDIS_TIMEOUT ise Redis yanıt vermezse WordPress'in ne kadar bekleyeceğini saniye cinsinden sınırlar; düşük bir değer, olası bir Redis sorununda sitenizin tamamen kilitlenmesini önler.
Aynı Redis sunucusunu birden fazla WordPress sitesi paylaşıyorsa, sitelerin birbirinin önbelleğini ezmemesi için her siteye ayrı bir "prefix" ve mümkünse ayrı bir veritabanı numarası vermelisiniz. Aksi halde iki site aynı anahtarları kullanır ve garip önbellek karışmaları yaşarsınız:
// Çoklu site kurulumlarında çakışmayı önlemek için
define( 'WP_REDIS_DATABASE', 0 ); // ikinci site için 1, üçüncü için 2...
define( 'WP_CACHE_KEY_SALT', 'site1_' ); // her siteye benzersiz bir önek verin
Redis belleği dolduğunda eski verilerin sessizce atılabilmesi ("least recently used" mantığı) çoğu zaman istenen davranıştır, çünkü önbellek verisi kaybolsa bile WordPress onu veritabanından yeniden üretir. Bunu Redis tarafında maxmemory ve maxmemory-policy ayarlarıyla yönetirsiniz:
# /etc/redis/redis.conf içine
maxmemory 256mb
maxmemory-policy allkeys-lru
Bu iki satır, Redis'in en fazla 256 MB kullanmasını ve sınıra ulaşınca en az kullanılan anahtarları otomatik silmesini sağlar; böylece bellek şişmesi kaynaklı sorunların önüne geçilir. Değişiklikten sonra sudo systemctl restart redis-server ile servisi yeniden başlatmayı unutmayın. Bu tür sunucu tarafı ince ayarları kendiniz yönetmek istemiyorsanız, sunucu yönetimi hizmetimizle bu yapılandırmayı uzman ekibimize bırakabilirsiniz.
Önbelleğin Çalıştığını Doğrulama#
Ayarları yaptıktan sonra "gerçekten çalışıyor mu" sorusuna tahminle değil, ölçümle yanıt vermelisiniz. İlk ve en kolay doğrulama noktası, eklentinin Ayarlar > Redis ekranıdır. Burada durumun Connected göründüğünü, ayrıca "Status" ve varsa isabet oranı (hit rate) gibi metriklerin dolu olduğunu görmelisiniz. İsabet oranı, önbellekten karşılanan isteklerin oranını gösterir; sağlıklı bir sitede kısa süre içinde yüksek değerlere (genellikle %90'ın üzeri) çıkar.
Daha teknik bir doğrulama için Redis tarafından bakabilirsiniz. WordPress önbelleğe veri yazıyorsa, Redis içindeki anahtar sayısı zamanla artar. Bunu canlı olarak izlemek için:
redis-cli info keyspace
# Örnek çıktı: db0:keys=1843,expires=integer,avg_ttl=0
keys değerinin sıfırdan büyük olması ve siteyi gezdikçe artması, WordPress'in aktif olarak Redis'e yazdığının en somut kanıtıdır. Daha da net görmek isterseniz, gelen komutları canlı akışta izleyebilirsiniz (yalnızca hata ayıklama için; üretimde açık bırakmayın çünkü performansı etkiler):
redis-cli monitor
Bu komut açıkken sitenizde birkaç sayfa gezinin; ekranda WordPress'in gönderdiği GET ve SET komutlarının akışını göreceksiniz. Bu, önbelleğin sadece bağlı değil, gerçekten kullanımda olduğunu gösterir.
Etkiyi somut olarak ölçmek isterseniz, önbellekten önce ve sonra bir sayfanın ürettiği veritabanı sorgu sayısını karşılaştırabilirsiniz. Query Monitor gibi bir hata ayıklama eklentisi, her sayfa için toplam sorgu sayısını gösterir. Object cache devredeyken bu sayının belirgin biçimde düştüğünü görürsünüz; işte object cache'in asıl işi budur. Aşağıdaki tablo, tipik bir kurulumda ne beklemeniz gerektiğini özetliyor:
| Gösterge | Object cache öncesi | Object cache sonrası |
|---|---|---|
| Sayfa başına DB sorgusu | Yüksek (ör. 60-120) | Belirgin düşük (ör. 15-30) |
| Yönetim paneli hızı | Yavaş, sorgu yoğun | Akıcı |
| Aynı sunucunun kapasitesi | Sınırlı | Daha fazla eşzamanlı ziyaretçi |
| Veritabanı CPU yükü | Yüksek | Düşük |
Sık Yapılan Hatalar ve İnce Ayarlar#
Object cache kurulumu genelde sorunsuzdur, ancak birkaç klasik tökezleme noktası vardır ve bunları önceden bilmek size zaman kazandırır. En sık karşılaşılan durum, eklentinin "Connected" gösterdiği halde sitede belirgin bir hızlanma hissedilmemesidir. Bunun en yaygın sebebi, sitede zaten iyi bir sayfa önbelleğinin çalışıyor olmasıdır; anonim ziyaretçiler sayfayı zaten hazır HTML olarak aldığı için object cache'in etkisi asıl olarak yönetim panelinde ve giriş yapmış kullanıcı deneyiminde hissedilir. Yani "kullanıcı tarafında fark yok" demek, object cache'in çalışmadığı anlamına gelmez.
İkinci sık hata, Redis'e parola tanımlanmış olmasına rağmen WP_REDIS_PASSWORD sabitinin eklenmemesidir. Bu durumda bağlantı sessizce başarısız olur ve eklenti "not connected" gösterir. Üçüncüsü, bir sorun yaşayıp Redis'i devre dışı bırakmak istediğinizde eklentiyi silmeden önce Disable Object Cache düğmesine basmayı unutmaktır; çünkü object-cache.php drop-in dosyası, eklenti klasörü silinse bile yerinde kalır ve WordPress hata vermeye devam edebilir. Doğru yol, önce panelden object cache'i kapatmak, sonra eklentiyi kaldırmaktır. Acil durumda drop-in'i elle de silebilirsiniz:
rm wp-content/object-cache.php
Bir başka faydalı ipucu da tuş temizleme (flush) konusudur. Redis'te biriken önbelleği tamamen sıfırlamak isterseniz, panelden "Flush Cache" düğmesini kullanabilir ya da komut satırından WP-CLI ile temizleyebilirsiniz:
wp cache flush
Son olarak, Redis'in belleğini ve güvenliğini gözden kaçırmayın. Redis'i her zaman yalnızca yerel adrese (127.0.0.1) bağlı tutun ve dışarıya kapalı olduğundan emin olun; yanlış yapılandırılmış, internete açık bir Redis ciddi bir güvenlik açığıdır. Bellek sınırı ve atma politikası (maxmemory-policy) ayarlanmadan bırakılan bir Redis, zamanla belleği doldurup sunucuyu zorlayabilir. Bu güvenlik ve kaynak yönetimi başlıklarının ayrıntısını Redis nedir rehberimizde bulabilirsiniz.
Sıkça Sorulan Sorular#
Redis object cache sayfa önbelleğinin yerine mi geçer?#
Hayır, ikisi farklı işler yapar ve birbirinin yerine geçmez. Sayfa önbelleği, üretilen tam HTML çıktısını saklayarak anonim ziyaretçilere WordPress'i hiç çalıştırmadan hazır sayfa sunar. Object cache ise HTML üretilirken kullanılan veritabanı sorgu sonuçlarını saklar ve özellikle giriş yapmış kullanıcı, WooCommerce ödeme adımı gibi kişiye özel dinamik sayfaları hızlandırır. En iyi sonucu ikisini birlikte kullandığınızda alırsınız.
Redis object cache kurmak için mutlaka VDS mi gerekir?#
Şart değil, ancak Redis'in sunucuda kurulu olması gerekir. Birçok paylaşımlı ve yönetilen WordPress hosting planında Redis sunucu tarafında hazır gelir; bu durumda yalnızca eklentiyi kurup etkinleştirmeniz yeterlidir. Sunucunuzda Redis kurulu değilse ve kendiniz kurmak istiyorsanız kök erişim gerekir; bu da VDS ya da sanal sunucu ile mümkündür. Sıfırdan uğraşmadan kullanmak isteyenler için Redis hazır sunulan WordPress hosting planları en pratik yoldur.
wp-config.php'ye hangi ayarları eklemem yeterli?#
Redis yerel adreste, varsayılan portta ve parolasız çalışıyorsa çoğu zaman hiçbir şey eklemenize gerek yoktur; eklenti varsayılan olarak 127.0.0.1:6379 adresine bağlanır. Ancak Redis'e parola tanımladıysanız WP_REDIS_PASSWORD, farklı bir port kullanıyorsanız WP_REDIS_PORT, aynı Redis'i birden fazla site paylaşıyorsa WP_CACHE_KEY_SALT ve WP_REDIS_DATABASE sabitlerini eklemeniz gerekir. Bu tanımlar wp-config.php dosyasında düzenlemeyi durduran yorum satırının üstüne yazılmalıdır.
Object cache açtım ama "not connected" görünüyor, ne yapmalıyım?#
Bu uyarı neredeyse her zaman üç sebepten birine bağlıdır. Ya sunucuda Redis servisi çalışmıyordur (redis-cli ping ile kontrol edin), ya PHP Redis eklentisi yüklü değildir (php -m | grep redis ile bakın), ya da wp-config.php içindeki bağlantı adresi, port veya parola yanlıştır. Bu üç noktayı sırayla doğruladığınızda sorunun kaynağı hızla ortaya çıkar. Redis'e parola tanımlıysa ancak WP_REDIS_PASSWORD eklenmemişse bağlantı sessizce başarısız olur; bu en sık gözden kaçan ayrıntıdır.
Redis çökerse sitem çöker mi?#
Doğru yapılandırıldığında hayır. Redis Object Cache eklentisi, Redis'e ulaşamadığında WordPress'in yerleşik geçici önbelleğine güvenli biçimde geri döner; yani veriler yine veritabanından çekilir, sadece önbellek hızından yoksun kalırsınız. Bu güvenli davranışı garanti altına almak için wp-config.php içinde düşük bir WP_REDIS_TIMEOUT değeri (örneğin 1 saniye) tanımlamanız önemlidir; böylece Redis yanıt vermezse WordPress uzun süre beklemeden normal çalışmasına devam eder.
Object cache WooCommerce mağazam için de faydalı mı?#
Evet, hatta object cache'in en çok fark yarattığı senaryolardan biri WooCommerce mağazalarıdır. WooCommerce sepet, ürün, stok ve kullanıcı bilgileri nedeniyle çok sayıda kişiye özel dinamik sayfa üretir ve bu sayfalar sayfa önbelleğinden yeterince faydalanamaz. Object cache, bu sayfalar üretilirken tekrarlanan ürün ve ayar sorgularını bellekten karşılayarak veritabanı yükünü belirgin biçimde azaltır ve mağaza gezinme deneyimini akıcılaştırır.
Kapanış#
Redis object cache, WordPress'in en görünmez yavaşlık kaynağı olan tekrarlı veritabanı sorgularını hedef alan, kurulumu kısa ama etkisi kalıcı bir optimizasyondur. Sunucuda Redis'in çalıştığını doğrulamak, PHP Redis eklentisini kurmak, Redis Object Cache eklentisini etkinleştirmek ve wp-config.php üzerinde birkaç sabiti tanımlamak; işte kalıcı nesne önbelleğine sahip bir WordPress kurulumu için gereken tek şey bu. Sayfa önbelleğiyle birlikte kullanıldığında ise site hem anonim ziyaretçilere hem de giriş yapmış kullanıcılara belirgin biçimde daha hızlı yanıt verir.
Bu adımlarla uğraşmadan Redis'i hazır çalışır halde kullanmak isterseniz, Clou.TR'nin WordPress hosting paketleri Redis ve önbellek yapılandırmasını sizin için baştan hazırlar. Tam kontrol ve kök erişim isteyen ekipler VDS sunucu üzerinde Redis'i istedikleri gibi yönetebilir; kurulum ve ince ayarları uzman desteğiyle yaptırmak isteyenler ise sunucu yönetimi hizmetimizle bu yükü tamamen bize bırakabilir.