CMS Performans ve Hız Ayarları: WordPress, Joomla, Drupal

CMS tabanlı sitelerde hız neden bu kadar kritik?

İster WordPress, ister Joomla, ister Drupal kullanıyor olun; ölçek büyüdükçe sorun genelde temadan önce altyapıda patlar. cms performans problemleri çoğu zaman yanlış yapılandırılmış PHP, veritabanı veya cache katmanından kaynaklanır. Tema değiştirmek, eklenti silmek bazen işe yarar ama sunucu tarafı zayıfsa asla yeterli olmaz.

Canlı sistem yöneten herkes bilir: Trafik bir anda ikiye katlandığında ilk darbe CPU, disk IO ve veritabanına gelir. Özellikle paylaşımlı hosting ortamında saniyeler içinde 504 hataları, timeout sorunları ve admin paneline bile girememe gibi sıkıntılar ortaya çıkmaya başlar. Bu yüzden en baştan, CMS’inizi taşıyacağınız VPS, bulut veya dedicated sunucuyu doğru seçmek ve mantıklı varsayılanlarla kurmak şart.

Burada odak, tek tek CMS ayarlarından çok altyapının üç katmanında olacak: web sunucusu ve PHP, veritabanı ve cache. WordPress hızlandırma, Joomla sunucu ayarları veya Drupal optimize çalışmaları yaparken temel prensip hep aynı: statik içeriği mümkün olduğunca önbellekten servis etmek, dinamik sorgu sayısını azaltmak ve ağır işlemleri arka plana taşımak.

Altyapı seçimi: VPS, bulut ve dedicated arasında denge

İyi ayarlanmamış güçlü bir dedicated sunucu, düzgün yapılandırılmış orta seviye bir VPS’ten çoğu zaman daha yavaş çalışır. Bu nedenle önce iş yükünü ve büyüme hızınızı doğru okumak gerekiyor.

• Az trafikli kurumsal site veya blog için genellikle 2 vCPU, 4 GB RAM ve hızlı SSD depolama iş görür.
• Yoğun eklentili WordPress, çok dilli Joomla veya ağır modüllü Drupal sitelerinde 4 vCPU, 8 GB RAM ve mümkünse NVMe diskle başlamak daha güvenlidir.
• E-ticaret, üyelik tabanlı sistemler veya çok yoğun API çağrısı alan projelerde ise sanal veri merkezi veya dedicated sunucu tercih edip kaynakları yatayda ölçeklemek daha sağlıklıdır.

Türkiye lokasyonlu, düşük gecikmeli bir altyapı arıyorsanız, CMS’inizi doğrudan paylaşımlı hosting yerine örneğin VPS.TC VPS ya da bulut sunucu üzerinde koşturmak size hem özgürlük hem de daha tutarlı performans sağlar. Kendi Nginx, PHP-FPM ve veritabanı versiyonlarınızı seçebilir, kernel parametrelerine kadar ince ayar yapabilirsiniz.

Burada en kritik nokta şu: Donanımı rastgele büyütmek yerine darboğaz nerede, önce onu tespit edin. CPU mu doluyor, RAM mi şişiyor, disk IO mu tıkanıyor, yoksa veritabanı sorguları mı yavaş? Ölçmeden yapılan her optimizasyon, üretim ortamında risk demek.

Web sunucusu ve PHP katmanında kritik ayarlar

PHP sürümü, OPcache ve FPM havuz ayarları

WordPress, Joomla ve Drupal’ın güncel sürümleri PHP 8.x ile ciddi performans kazanıyor. Eski bir 7.x sürümünde 200 ms süren bir PHP isteği, doğru yapılandırılmış PHP 8.1 ile 120–130 ms civarına inebiliyor. Bu yüzden ilk adım, CMS’inizin desteklediği en güncel, kararlı PHP sürümüne geçmek olmalı.

İkinci adım, OPcache’i aktif edip düzgün ayarlamak. OPcache, PHP dosyalarını derlenmiş halde bellekte tuttuğu için her istek başına dosya okuma ve derleme maliyetini ortadan kaldırır. Tipik bir üretim ortamında şu değerlerle başlamak mantıklı:

• opcache.enable = 1
• opcache.memory_consumption = 256 (veya trafik yoğunluğunuza göre 512)
• opcache.max_accelerated_files = 20000
• opcache.validate_timestamps = 0 (sadece deploy sürecini kontrol edebiliyorsanız)

PHP-FPM havuz ayarları, özellikle yüksek trafikli WordPress hızlandırma senaryolarında büyük fark yaratır. Çok düşük değerlerle site kitlenir, çok yüksek değerlerle de RAM patlar. Basit bir örnek konfigürasyon şöyle olabilir:

[www]
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500

Buradaki değerler her sistem için geçerli değildir; mutlaka canlı öncesi test ortamında denemelisiniz. Özellikle pm.max_children değerini, RAM kullanımını ve ortalama PHP süreç başına tüketilen belleği ölçerek belirlemek gerekir. Aksi halde anlık trafik artışlarında OOM (Out Of Memory) ile tüm PHP-FPM’in çökmesine sebep olursunuz.

Nginx veya Apache için bağlantı ve sıkıştırma ayarları

Web sunucusu tarafında ana hedef; aynı anda mümkün olduğunca fazla isteği yönetmek ve her bir isteğin ağ üzerinden olabildiğince küçük boyutta taşınmasını sağlamaktır.

Nginx kullanıyorsanız, keepalive ve gzip ayarlarını mantıklı seviyelerde tutmak önemli:

http {
    keepalive_timeout  15;
    sendfile           on;
    tcp_nopush         on;

    gzip on;
    gzip_comp_level 5;
    gzip_types text/css application/javascript application/json image/svg+xml;
}

Apache kullanıyorsanız event MPM ve mod_http2 ile birlikte PHP-FPM entegrasyonu (mod_php yerine proxy_fcgi) genellikle daha ölçeklenebilir bir yapı sunar. Aynı şekilde, mod_deflate veya mod_brotli ile sıkıştırma sağlayarak özellikle HTML, CSS ve JS boyutlarını ciddi oranda küçültebilirsiniz.

Burada yapılan yaygın hata, her şeyi maksimuma açmak. Örneğin gzip_comp_level değerini 9 yapmak CPU’yu gereksiz yorarken kazandığınız bant genişliği çoğu senaryoda anlamlı olmaz. Üretim ortamında her değişikliği önce test edip, ardından canlıya alırken eş zamanlı izleme yapmalısınız.

Veritabanı katmanını ayarlamak

MySQL/MariaDB için temel tampon ve bağlantı ayarları

WordPress, Joomla ve Drupal’ın büyük çoğunluğu MySQL veya MariaDB üzerinde çalışıyor. Veritabanı yavaşsa, en mükemmel PHP ve cache optimizasyonu bile toplam süreyi kurtaramaz.

İlk bakılması gereken yer, InnoDB yapılandırmasıdır. Özellikle innodb_buffer_pool_size parametresi çok küçüksa, her sorguda diskten okuma yapıldığı için gecikme artar. Genel bir kural olarak, veritabanınızın aktif veri setinin mümkün olduğunca büyük kısmını RAM’de tutmaya çalışın.

[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size    = 1G
max_connections         = 200
query_cache_type        = 0
query_cache_size        = 0

Eski alışkanlıklarla hâlâ query_cache açan çok yönetici görüyorum. Modern InnoDB ile query cache çoğu zaman yarardan çok zarar veriyor; kilitlenmelere ve bekleme sürelerine sebep olabiliyor. O yüzden kapalı bırakmak daha güvenli.

max_connections değerini de abartmadan, gerçekten ihtiyaç duyduğunuz seviyede tutun. 1000 bağlantı limiti koyup RAM yetmediği için swap’e düşen, sonra da tüm siteleri duran sistemler görmek maalesef çok yaygın.

CMS seviyesinde temizlik ve indeks kullanımı

WordPress hızlandırma çalışmalarında gereksiz revizyon kayıtları, otomatik taslaklar ve şişmiş wp_options tablosu klasik sorunlardır. Düzgün bir bakım takvimi ile:

• Eski revizyonları ve otomatik taslakları temizleyebilir,
• Autoload edilen ama artık kullanılmayan seçenekleri kaldırabilir,
• Yoğun sorgu alan tablolara eksik indeksleri ekleyebilirsiniz.

Joomla ve Drupal tarafında da benzer şekilde log ve oturum tabloları zamanla şişer. Özellikle Drupal’da watchdog (log) tabloları temizlenmezse hem disk hem de sorgu süreleri açısından ciddi yük oluşturabilir.

Bu temizlik işlemlerini asla doğrudan üretim veritabanında denemeyin. Önce yedeği alın, tercihen staging ortamında test edin, ardından bakım penceresi açıp canlı sistemde uygulayın. Yanlış bir silme komutu, saniyeler içinde tüm sitenizi kullanılmaz hale getirebilir.

WordPress hızlandırma için sunucu odaklı pratikler

WordPress ekosisteminde binlerce cache eklentisi var; fakat asıl kazanım, bu eklentileri doğru yapılandırılmış bir sunucu ortamıyla birleştirdiğinizde ortaya çıkar.

Öncelikle PHP tarafında OPcache’in stabil çalıştığından emin olun. Sonrasında, objekt cache için Redis veya Memcached tercih etmek, özellikle çok sorgu yapan eklentilerde hissedilir bir rahatlama sağlar. Redis için tipik bir kurulumdan sonra wp-config.php içine bağlantı bilgilerini eklemek yeterlidir.

Yoğun trafik alan sitelerde WordPress cron sistemini gerçek cron’a taşımak da gecikmeleri azaltır. Aksi halde her kullanıcı isteğinde cron tetiklenmeye çalışır ve kimi zaman sayfa yüklenmesini geciktirir.

define('DISABLE_WP_CRON', true);

Bu satırdan sonra sistem cron’unda dakikada bir çalışan bir görev ekleyebilirsiniz:

# WordPress cron'u gerçek cron üzerinden çalıştırmak için
* * * * * www-data php /var/www/site/public/wp-cron.php >/dev/null 2>&1

Nginx kullanıyorsanız, WordPress için FastCGI cache yapılandırmak, özellikle anonim kullanıcı trafiğinde sayfa yanıt sürelerini milisaniye seviyesine çekebilir. Buradaki kritik nokta; giriş yapmış kullanıcıları, sepeti olan ziyaretçileri veya özel cookie taşıyan istekleri önbelleğe almamaktır.

Depolama tarafında da küçük ama etkili dokunuşlar var: Resimleri otomatik sıkıştıran ve WebP formatına çeviren çözümler, CDN kullanımı ve HTTP/2 desteği, WordPress hızlandırma sürecinde göz ardı edildiğinde ciddi fırsat kaybı yaratır.

Joomla sunucu ayarları ile kararlı hız

Joomla yapısı gereği modüller ve eklentiler üzerinden genişletildiği için, kötü yazılmış birkaç eklenti tüm siteyi yavaşlatabilir. Ancak sunucu tarafında alacağınız önlemlerle bu etkiyi sınırlamak mümkün.

Öncelikle PHP sürümünü güncel tutup OPcache’i etkinleştirin. Ardından Joomla’nın dahili cache mekanizmasını etkinleştirip, mümkünse dosya tabanlı cache yerine Redis veya Memcached gibi bellek tabanlı çözümler kullanın. Bu, hem CPU hem de disk IO yükünü azaltır.

Joomla sunucu ayarları tarafında dikkat edilmesi gereken başlıklar:

• Gzip veya Brotli sıkıştırmasını web sunucusu seviyesinde etkinleştirmek,
• Session verisini dosya yerine Redis gibi kalıcı bir store’da tutmak,
• PHP-FPM havuzunu özellikle admin trafiğini hesaba katarak boyutlandırmak,
• Gereksiz Apache modüllerini kapatmak veya Nginx tarafında fazla kural yükünü azaltmak.

Admin panelinde yapılan yapılandırma değişikliklerini canlıya almadan önce staging bir Joomla kopyasında test etmek, özellikle cache ve sıkıştırma ayarlarında bozulmaları önler. Yanlış bir .htaccess kuralı, tüm siteyi 500 hata ekranına çevirebilir.

Drupal optimize ipuçları

Drupal, esnekliği ve modüler yapısı sayesinde büyük projelerde sık tercih ediliyor; ama yanlış yapılandırıldığında çok ağır çalışabiliyor. Burada da sunucu tarafı ayarları önemli bir kaldıraca dönüşüyor.

İlk olarak, Drupal’ın cache sistemini tam anlamıyla kullanabilmek için PHP OPcache, APCu veya Redis gibi bileşenleri devreye alın. Çoklu sunucu senaryolarında, Redis üzerinden paylaşılan cache ve session yönetimi ciddi tutarlılık sağlar.

Asset (CSS ve JS) birleştirme ve küçültme ayarlarını aktif etmek, özellikle ilk yüklenme süresini iyileştirir. Aynı zamanda HTTP/2 ve mümkünse HTTP/3 desteği olan bir ters proxy (örneğin Nginx) arkasında Drupal koşturmak da paralel istek sayısını ve gecikmeyi iyileştirir.

Drupal optimize çalışmaları sırasında log ve cron yapılandırmasını da atlamayın. Yoğun log tutan modüller diski doldurabilir, düzenli çalışmayan cron görevleri ise cache temizliği gibi kritik işlemleri aksatabilir. Özellikle cron tetikleme sıklığı ile trafik profilinizi birbiriyle uyumlu hale getirmelisiniz.

Bir diğer nokta da veritabanı sorgularının izlenmesi. Drupal’da yavaş sorguları yakalamak için veritabanı loglarını ve gerekiyorsa uygulama seviyesindeki profil araçlarını kullanın. Bu sorgulara uygun indeks eklemek, kimi zaman donanımı iki katına çıkarmaktan daha etkili sonuç verir.

İzleme, log analizi ve sürekli iyileştirme için yol haritası

Sunucunuza SSH ile bağlandığınızda ilk yapmanız gereken, anlık durumu görmek olmalı. Örneğin htop veya top ile CPU ve RAM kullanımını, iostat ile disk IO’yu, netstat veya ss ile de bağlantı durumlarını incelemek iyi bir başlangıçtır.

# Temel canlı izleme komutları
htop
iostat -x 1
vmstat 1
ss -tnp | head

Bu komutlar size nerede tıkanma olduğunu gösterir: CPU mu dolu, disk mi kilitlenmiş, yoksa yüzlerce bekleyen TCP bağlantısı mı var? Sonrasında web sunucusu logları (access ve error), PHP-FPM logları ve veritabanı slow query log’u ile tabloyu netleştirebilirsiniz.

Her büyük değişiklikten önce mutlaka tam yedek alın: dosya sistemi, veritabanı ve mümkünse snapshot bazlı disk yedeği. Özellikle VDS veya bulut sunucu kullanıyorsanız, snapshot’lar hızlı geri dönüş için hayat kurtarır. Canlı ortamda yaptığınız her ayarın geri dönüş yolunu baştan planlayın.

İlerlerken şu basit döngüyü uygulamak işinizi kolaylaştırır:

• Ölç: CPU, RAM, disk IO, sorgu süreleri ve yanıt sürelerini izle.
• Darboğazı bul: En çok kaynak tüketen bileşeni tespit et.
• Hedefli değişiklik yap: Sadece ilgili katmanda ayar değiştir.
• Tekrar ölç: Değişikliğin etkisini rakamlarla gör.

Böylece rastgele hamleler yerine, gerçekten etkili optimizasyonlar yapmış olursunuz. WordPress hızlandırma, Joomla sunucu ayarları veya Drupal optimize süreçlerinin hepsinde bu yaklaşım geçerli.

İlk adım olarak mevcut sunucunuzda küçük bir performans envanteri çıkarın: Hangi PHP sürümü kullanılıyor, OPcache aktif mi, veritabanı tamponları yeterli mi, cache mekanizması nasıl çalışıyor? Ardından burada paylaştığım ayarları test ortamında deneyip, canlıya kontrollü şekilde geçin. Birkaç hafta sonra, doğru yapılandırılmış bir altyapının cms performans üzerinde ne kadar dramatik fark yarattığını net şekilde göreceksiniz.