WordPress için optimum PHP/MySQL ayarları: Net rehber

WordPress sitelerinde hız ve kararlılık çoğu zaman “hangi hosting” sorusundan önce, PHP ve MySQL’in nasıl ayarlandığına bağlıdır. Yanlış bellek sınırları, yetersiz bağlantı havuzu veya agresif cache ayarları; sayfa yüklenmesini yavaşlatır, bazen de veri kaybına giden kilitlenmelere yol açar. Bu rehberde PHP (özellikle PHP-FPM) ve MySQL için hedef odaklı, ölçülebilir ayar mantığını anlatıyor; tipik bir WordPress yükünde neyi nasıl konfigüre edeceğinizi netleştiriyoruz.

Aşağıdaki adımlar tek seferlik “ayar yap bitti” değildir. Amaç, mevcut yükünüzü ölçüp (bench) ardından değişiklikleri küçük paketler halinde uygulamak, performansı izlemek ve sonuçları karşılaştırmaktır. Böylece “en iyi ayar” yerine “sizin sunucunuza en uygun ayar” yaklaşımını benimsersiniz.

1) Başlamadan önce hedefi netleştirin: WordPress yük profili

Önce sorun türünü belirleyin. Aynı ayar her sunucuda aynı sonucu vermez.

En yaygın 3 performans problemi

• CPU tavanı: PHP işlemcileri yetişmiyor, istekler yığılmaya başlıyor.
• RAM baskısı: MySQL veya PHP bellek kullanımı artıyor, swap’a düşme riski oluşuyor.
• Disk/IO darboğazı: özellikle InnoDB log yazımı veya yavaş disk nedeniyle gecikme büyüyor.

Ölçüm için minimum metrik paketi

Sunucuya göre değişse de şu metrikler yön verir: - Web istekleri: ortalama yanıt süresi (TTFB), 95. persentil gecikme - PHP-FPM: listen queue büyüyor mu, aktif worker sayısı doygun mu - MySQL: Threads_connected, yavaş sorgu (slow query) sayısı - Sistem: CPU iowait, RAM swap kullanımı

Bu metrikleri topladıktan sonra ayar değiştirin. Değişiklik sayısını artırmak yerine her seferinde küçük bir parametre grubunu ele almak, “hangi ayar işe yaradı?” sorusunu netleştirir.

2) PHP için optimum yaklaşım: PHP-FPM + bellek sınırları

WordPress için pratik hedef: PHP’nin istekleri işleyebilmesi için yeterli worker sayısını sağlamak, fakat RAM’i tüketmeden çalışmak.

WordPress ortamında temel PHP-FPM parametre mantığı

PHP-FPM’de dikkat edeceğiniz değişkenler genelde şunlardır: - pm.max_children: Aynı anda çalışabilecek en fazla PHP işlemi - pm.start_servers / pm.min_spare_servers / pm.max_spare_servers: İşlem havuzu davranışı - pm.max_requests: Worker yeniden doğma eşiği (uzun süreli sızıntı/fragmentasyon riskini azaltır) - request_terminate_timeout: Takılan istekler için tavan

Tipik başlangıç mantığı (hesap iskeleti)

• Sunucunuzun RAM’ini “PHP worker başına” ayırın.
• Her worker için PHP tarafında en yüksek bellek kullanımını yaklaşık hesaplarsınız (genelde memory_limit ve WordPress eklenti davranışları belirler).

Örnek mantık (tam sayı garanti değildir): - memory_limit = 256M varsayalım. - PHP-FPM’de 200-300MB civarı overhead (OPcache, yığın, süreç payı) eklemek gerekebilir. - 2GB RAM’li bir ortamda pm.max_children için 6-10 aralığıyla başlanır, gözleme göre artırılır.

Net hedef: “pm.max_children büyük olsun” değil; o anda çalışanların sayısı RAM’i zorlamadan yeterli throughput sağlamalı.

PHP tarafında mutlaka kontrol edilecek ayarlar

1) opcache (OPcache) - WordPress için OPcache açık olmalı. - Amaç: PHP derlemelerini tekrar tekrar yapmamak.

2) memory_limit - Aşırı düşük değer eklentilerde hata çıkarır; aşırı yüksek değer RAM’i sömürür. - WooCommerce, büyük cache eklentileri ve görsel işleme süreçleri memory tüketebilir.

3) max_execution_time / max_input_time - Uzun çalışan import/arka plan işlemleri gerekiyorsa doğru yaklaşım “tavanı sınırsız yükseltmek” değildir. - Bunun yerine arka plan işlerini queue/CLI ile yönetmek daha net bir çözümdür.

Net kural: Tek değişken değil, 3’lü set

PHP-FPM’de genelde tek parametre değiştirmek yetmez. Şunları birlikte düşünün: - memory_limit - pm.max_children - request_terminate_timeout

3) MySQL optimum ayarlar: InnoDB odaklı net yapı

WordPress MySQL’inde asıl yük InnoDB tablo işlemleri ve sorgu planıdır. Bu yüzden sadece bağlantı sayısını artırmak değil; bellek havuzlarını ve log davranışını doğru kurmak gerekir.

Temel hedefler

• buffer pool (InnoDB): Sık kullanılan veri sayfalarını RAM’de tutmak
• connection yönetimi: Çok aç-kapa yerine kontrollü bağlantı
• redo/undo log: Yazım performansı ve bekleme davranışı
• slow query: sorunu büyütmeden tespit

İnnoDB buffer pool boyutu

En önemli parametre genelde şudur: - innodb_buffer_pool_size

Net yaklaşım: - Sunucunuzun toplam RAM’ini kullanırken, işletim sistemi ve diğer bileşenleri (PHP-FPM, cache) göz önünde bulundurun. - MySQL buffer pool’u RAM’in “büyük kısmı” olacak şekilde planlanır; ama swap’a düşecek kadar artırılmaz.

Pratik kural: - MySQL’i tek büyük süreç olarak düşünüyorsanız bile, PHP-FPM worker’lar için RAM ayırmadan buffer pool’u şişirmeyin.

Bağlantı ve thread ayarı

WordPress’te trafik dalgalı olduğunda bağlantı sayısı kısa süreli sıçrayabilir. - max_connections: üst tavan - thread_cache_size: thread yeniden kullanımı

Net kural: - max_connections değerini “büyüt kurtul” olarak yükseltmeyin. - Asıl amaç, uygulamanızın bağlantıları verimli kullanmasıdır. Aksi halde çok bağlantı RAM/CPU maliyeti doğurur.

Slow query log ile iyileştirme döngüsü

• slow_query_log açık olsun (gerekli süre boyunca).
• long_query_time değerini makul tutun (ör. 1-2 saniye başlangıç için net bir eşiktir).

Yorum yapmadan net aksiyon: 1) Slow sorguları toplayın. 2) Hangi tablo/eylem yavaş: görsel dönüşümü değil, sorgu ise indeksi/kompozisyonu ele alın. 3) PHP tarafındaki cache ile birlikte SQL tarafını düzeltin.

4) WordPress tarafı ile ayarları birlikte düşünün: cache ve bağlantı maliyeti

PHP ve MySQL ayarları, WordPress cache stratejisiyle birlikte anlam kazanır. Dinamik sayfada her isteği MySQL’e çektirmek, iyi ayarsanız bile tıkanmaya yol açar.

Görünür fark yaratan 5 konu

• Sayfa cache (tam sayfa) etkin mi?
• Object cache var mı? (ör. Redis/Memcached)
• Veritabanı optimizasyonu düzenli mi?
• CDN kullanımı doğru mu? (özellikle görseller)
• Staging/deneme ortamında değişiklik yapılıyor mu?

Redis ile object cache örneği (mantık)

Object cache açık olduğunda WordPress bazı sorguları daha az tekrarlar. Bu, MySQL connection ve CPU yükünü düşürür.

5) Ölçümden sonra net uygulama planı (adım adım)

Aşağıdaki plan, sunucuda “ayarları rastgele” denemeden ilerlemenizi sağlar.

Hedef senaryo tanımı

Bir WordPress VDS/VPS’de tipik olarak şu hedeflerle ilerlenir: - 95. persentil yanıt süresini düşürmek - PHP-FPM kuyruk büyümesini engellemek - MySQL’de yavaş sorgu sayısını ve gecikmeyi azaltmak

Adım adım değişiklik sırası

1) OPcache durumunu kontrol edin (PHP) 2) PHP-FPM worker sayısını RAM’e göre sınırlayın 3) MySQL buffer pool boyutunu RAM dengesine göre ayarlayın 4) Slow query log ile sorunlu sorguları listeleyin 5) WordPress cache/object cache katmanını doğrulayın

Uygulama sonrası kontrol listesi

• PHP-FPM: pm.max_children sınırına düzenli şekilde takılıyor mu?
• MySQL: swap kullanımı başladı mı?
• Yavaş sorgu sayısı azaldı mı?
• CPU iowait arttı mı? (özellikle disk IO)

6) Hızlı referans: Boyutlara göre öneri aralıkları (başlangıç değerleri)

Aşağıdaki tablo “mutlak en iyi” değil; net bir başlangıç çerçevesi sağlar. Değerleri, sunucu RAM/CPU ve WordPress eklenti yoğunluğunuza göre doğrulayın.

Net kaçınma listesi

• PHP-FPM’de pm.max_childreni sınırsız yükseltmeyin: RAM taşarsa tüm trafik etkilenir.
• MySQL max_connectionsi “çözüm” gibi artırmayın: asıl sorun bağlantı verimsizliği veya yavaş sorgu olabilir.
• OPcache’i kapalı bırakmayın.
• Slow query log’u hiç izlemeyin: performans tuning yerine tahmin yapılır.

Sonuç: Yapılandırmayı tek seferde değil, ölçerek tamamlayın

WordPress için optimum PHP/MySQL ayarlarında en net yol, önce performans darboğazını (CPU/RAM/IO) belirlemek, ardından PHP-FPM worker dengesini kurmak ve MySQL tarafında InnoDB buffer pool ile yavaş sorguları hedeflemektir. Aksiyon önerisi: Sunucunuzda 1-2 gün ölçüm toplayın, OPcache ve PHP-FPM worker ayarlarını kademeli uygulayın; paralel olarak MySQL slow query log ile sorguları tespit edip WordPress cache/object cache katmanını doğrulayın. Böylece ayarlarınız “genel tavsiye” değil, sizde gerçekten çalışan bir optimizasyon seti haline gelir.