WordPress için optimum PHP/MySQL ayarları (2026 net rehber)

WordPress’in hızını ve kararlılığını belirleyen en kritik katmanlar PHP çalıştırma motoru (çoğunlukla PHP-FPM) ve veritabanı (genellikle MySQL veya MariaDB) tarafıdır. Yanlış PHP uzantıları, etkin olmayan opcode önbellekleme, yetersiz bağlantı/queue ayarları veya yavaş sorgular; hem TTFB’yi hem de sayfa yüklenme sürelerini doğrudan etkiler. Bu rehberde 20.08.2026 gerçekleriyle uyumlu şekilde, WordPress için PHP/MySQL’de net hedefleri (daha düşük gecikme, daha az hata, daha stabil kapasite) hangi parametrelerle yakalayacağınızı öğreneceksiniz.

Aşağıdaki ayarlar; paylaşımlı hosting değil, VDS/VPS veya kendi kontrol paneli olan ortamlar için yazılmıştır. Panel erişiminiz yoksa yine de kontrol kalemlerini izleyip “hangi değeri kim değiştirebiliyor” sorusunu netleştirirsiniz.

PHP tarafı: WordPress için doğru çalışma modeli ve limitler

WordPress’te asıl kritik konu “PHP sürümü + FPM ayarı + opcode önbellek” üçlüsüdür. Basitçe: WordPress’in PHP kodunu her istek için yeniden derlemek yerine opcode önbellekte tutmak, CPU maliyetini azaltır ve TTFB’yi düşürür.

1) PHP sürümü ve modüler uzantılar

• PHP sürümü: WordPress’in desteklediği en güncel sürüme yakın (2026’da pratikte 8.2/8.3 bandı hedeflenir).
• Zorunlu uzantılar (WordPress’in çalışması için): mysqli (veya pdo_mysql), curl, mbstring, zip, xml, gd (tema/medya gereksinimine göre), imagick (opsiyonel).
• Otomatik devreye giren ancak gereksiz yük bindirenleri kapatın: Örneğin kullanılmayan debug uzantıları, geliştirme modları.

Net kontrol: Tema eklentileriniz için gerçekten gerekli olmayan PHP uzantıları azaldıkça istek başına daha düşük bellek ve daha düşük başlangıç maliyeti görürsünüz.

2) PHP-FPM: işçi (worker) sayısı ve havuzlama

PHP-FPM’de hedef, gelen istekleri “bekletmeden” işlemek; fakat her CPU çekirdeğine körlemesine worker açmak da bellek taşmasına yol açar. Bu yüzden işçi sayısını RAM ve CPU’ya bağlamak gerekir.

Aşağıdaki değerler başlangıç için referanstır (son değeri metrikle doğrulayın):

• pm = dynamic
• pm.max_children: Toplamda sisteme sığacak şekilde; aşım olursa OOM (Out of Memory) riski artar.
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers: İstek az olduğunda bile çok fazla kaynak ayırmamak için ayarlanır.

Net öneri mantığı (kaba hesap): - Sunucuda toplam RAM’in tamamını PHP’ye vermezsiniz. Sistem için %20-25 pay bırakın. - Her PHP worker ortalama kaç MB bellek kullanıyorsa (ölçümden sonra), pm.max_children onu aşmamalı.

/status benzeri FPM durum sayfaları (mevcutsa) veya sistem metrikleriyle “peak” değerleri yakalayın.

3) OPCache: WordPress için “derleme maliyetini” sıfıra yaklaştırma

PHP opcode önbelleği etkin değilse her istek PHP kodunu yeniden derleyebilir. Bu, özellikle eklenti sayısı ve tema şablonları fazla olduğunda fark edilir.

Referans ayarlar:

• opcache.enable=1
• opcache.memory_consumption=128 (yoğun trafikte 192/256 değerlere çıkılabilir)
• opcache.interned_strings_buffer=16–32
• opcache.max_accelerated_files=4000–10000 (site büyüklüğünüze göre)
• opcache.validate_timestamps=0 (üretim için); kod değiştikçe FPM/servis yeniden başlatma ile cache temizlenir.
• opcache.revalidate_freq=0

Net kural: Üretimde dosya sık değişmiyorsa validate_timestamps=0 daha tutarlı performans verir. Geliştirme ortamında ise dosya değişimlerini anında görmeniz gerektiği için etkinleştirme mantığı değişir.

4) PHP worker başına bellek ve zaman aşımı

• memory_limit: WordPress’in eklenti/tema kullanımına göre artırın. Çok düşük limit, yükleme sırasında fatallere yol açar.
• max_execution_time ve max_input_time: Uzun çalışan süreçlerde (ör. büyük import, cron işleri) yeterli olmalı.

Net hedef: 30x saniyede bitmesi gereken istekleri “sonsuz uzatmak” yerine doğru süreçleri cron/queue ile ayırın. Burada amaç “timeout ile başarısız HTTP isteği sayısını azaltmak”.

5) Üç kritik başlık: HTTP cache, gzip/brotli ve request boyutu

PHP/MySQL ayarı tek başına yetmez; ama hızlı test için şunları doğrulayın:

• Sunucu seviyesinde gzip/brotli açık mı?
• Statik içerik için uygun Cache-Control var mı?
• client_max_body_size veya benzer limitler (Nginx/Apache) upload/REST isteklerinde hata üretmesin.

MySQL tarafı: bağlantı yönetimi, bufferlar ve disk I/O dengesi

WordPress’te MySQL performansı çoğu zaman “query optimizasyonu” kadar “doğru buffer ve bağlantı ayarı” ile de iyileşir. Burada net ölçüm: yavaş sorgular kadar lock (kilit) ve yüksek bağlantı sayısı da gecikmeye neden olur.

1) Temel parametreler: max_connections ve thread davranışı

WordPress yoğunluğu arttıkça, PHP-FPM worker sayısı ile MySQL bağlantı sayısı arasında doğrudan ilişki oluşur.

Başlangıç kontrol listesi:

• max_connections: PHP tarafındaki eşzamanlı worker’larla uyumlu olmalı.
• Bağlantı havuzu varsa (örn. ProxySQL/pgbouncer benzeri) WordPress için de bağlantı sayısını azaltma etkisi yaratır.

Net öneri: “MySQL çok hızlı yanıt vermiyor” şikayetinin altında bazen sorgu değil, bağlantı birikmesi vardır. Bu durumda max_connections değerini artırmak anlık rahatlama sağlar; ama altta CPU/RAM/diski zorlayan başka sorun varsa çözüm olmaz.

2) InnoDB buffer pool: en büyük kaldıraç

WordPress tablolarının çoğu InnoDB olduğu için asıl büyük kazanç genelde InnoDB buffer pool büyüklüğündedir.

Referans mantık: - Sunucunuzdaki RAM’in önemli bir kısmını InnoDB’ye ayırın. - Genel hedef: Buffer pool boyutunu çalıştığınız veri setini büyük oranda cache’leyecek seviyede tutmak.

Net hedef (kural): Buffer pool çok küçükse her sorgu disk okumasına döner ve latency yükselir. Çok büyükse sistem swap’a düşer ve tüm performans bozulur.

3) Redo log ve günlük (log) ayarları

Yoğun yazma (örn. yorumlar, eklenti süreçleri, sık güncellemeler) olan ortamlarda redo log boyutu ve flush davranışı önemlidir. Ama burada her sistem farklı olduğu için doğru ayar ölçümle yapılmalıdır.

• innodb_flush_log_at_trx_commit: Dikkatli düzenleyin. Tam ayar değişimi; veri kaybı riskini ve performansı birlikte etkiler.
• innodb_log_file_size: Çok küçükse checkpoint maliyeti artabilir.

Net öneri: Uç değer oynamak yerine, önce yavaş sorgu/lock haritasını çıkarın. Ardından yazma trafiği ölçümünü temel alarak ilerleyin.

4) Kararlı performans için karakter set / collation uyumu

WordPress kurulumunda doğru karakter set kullanımı önemlidir.

• character_set_server ve collation_server WordPress standartlarına uyumlu olmalı.

Net hedef: Karakter set uyuşmazlığı, bazı sorgularda ek maliyet yaratır ve içerik eşleşmelerinde problemleri büyütebilir.

5) Query cache: MySQL 8+ davranışı ve WordPress etkisi

MySQL 8 ile birlikte query cache kaldırıldığı/etkisizleştiği durumlar vardır. Bu nedenle “query cache açın rahatlayın” yaklaşımı artık geçerli değildir.

Net kural: WordPress tarafında asıl kazanç query optimizasyonu + indeks + doğru bufferlar üzerinden gelir.

WordPress uyumluluğu: doğru ayarların doğru yerde olması

WordPress’te performans iyileştirmeleri çoğu zaman PHP/MySQL’den daha geniştir (objekt cache, page cache, cron düzeni), ancak PHP/MySQL’de hata kaynakları şunlardır:

• WP_DEBUG veya debug log’ların açık kalması
• Her istekte çalıştırılan ağır eklentiler
• wp-cron’un gerçek tetiklenmemesi ve “yığılma” yaratması
• Veri tabanında indeks eksikliği veya gereksiz sorgular

1) Veritabanı hedefi: slow query ve lock analizi

Net ölçüm olmadan “şu parametre iyi” demek yanıltıcıdır. Şu yaklaşımı izleyin:

• Slow query log’u açın ve örnek sorguları toplayın.
• Threads_running, Threads_connected, Created_tmp_disk_tables gibi metriklere bakın.
• Lock beklemeleri varsa hangi tablolar/işlemler geciktiriyor inceleyin.

Somut çıktı hedefi: En az 24-48 saatlik logdan “top 10 yavaş sorgu” listesini çıkarmak.

2) İndeks ve şema temizliği

WordPress çekirdeğinde indeks mantığı genellikle hazır olsa da eklentiler kendi tablolarını oluşturabilir. Şu net adımları alın:

• Gereksiz büyük tabloları tespit edin.
• Eklentilerin kullandığı tablolar için doğru indeks var mı kontrol edin.
• Periyodik “post revisions” temizliği, veritabanını şişirme etkisini azaltır.

3) Objeleri önbelleğe alma: MySQL yükünü düşürün

WP tarafında objekt cache (örn. Redis/Memcached) kullanımı MySQL isteklerini azaltır. Bu rehber PHP/MySQL odaklı olsa da pratikte şu sonuca götürür:

• Aynı sorguların tekrar tekrar MySQL’e gitmesi azalır.
• PHP worker başına düşen DB round-trip sayısı düşer.

Net öneri: Eğer altyapınız uygunsa Redis + PHP-FPM + OPCache üçlüsü birlikte ele alınmalıdır.

Somut karşılaştırma: farklı senaryolarda önerilen ayar yaklaşımı

Tek bir “evrensel PHP/MySQL ayarı” yok. Aşağıdaki tabloda senaryoya göre nasıl karar verdiğinizi net biçimde görürsünüz.

Uygulama planı: 30-60 dakikada net iyileştirme rotası

Aşağıdaki plan, “ayarı değiştir, ne oldu?” belirsizliğini azaltır.

Adım 1: Başlangıç ölçümü (10-15 dk)

• 5-10 sayfa türü seçin: ana sayfa, kategori, ürün/sayfa, arama sonucu, sık kullanılan bir yazı.
• Her biri için: TTFB, toplam yüklenme, hata oranı.
• MySQL’de: slow query örnekleri, Threads_running trendi.

Adım 2: PHP-FPM + OPCache (15-25 dk)

• OPCache kapalıysa açın.
• PHP-FPM worker parametrelerini RAM’e göre sınırlayın.
• Sonra servis reload yapın.

Adım 3: MySQL buffer pool (10-15 dk)

• Buffer pool değerini ölçümle büyütün.
• Disk okuma azalıyor mu, swap riski oluşuyor mu takip edin.

Adım 4: Query/lock düzeltmesi (planlı, 1-3 gün)

• En yavaş 10 sorguyu düzeltin: indeks, sorgu revizyonu.
• Lock bekleyen tabloları hedefleyin.

Güvenlik ve dayanıklılık için PHP/MySQL’de “net” eklemeler

• MySQL kullanıcı izinleri: WordPress için ayrı kullanıcı, sadece gerekli yetkiler.
• Uzaktan erişim: MySQL portunu sadece uygulamanın geldiği ağlara açık tutun.
• Yedekleme (backup): Günlük otomatik yedek + dosya yedekleme. DB yedeği geri yükleme testini en az ayda bir yapın.
• Log rotasyonu: Çok büyüyen loglar diski doldurur; performans değil, erişim sorunu üretir.

Sonuç: PHP-FPM + OPCache + InnoDB ile başlayın, sonra sorgu/lock’a geçin

WordPress’te optimum PHP/MySQL ayarları; rastgele parametre artırma değil, önce ölçüm, sonra kademeli değişim ve en sonda slow query/lock giderme işidir. İlk 60 dakikada en net kazanç genellikle OPCache ve PHP-FPM worker dengesiyle gelir; ikinci aşamada InnoDB buffer pool ile MySQL disk okumasını düşürürsünüz. Ardından slow query log’dan çıkan en ağır sorguları indeks/query revizyonuyla çözdüğünüzde kalıcı performans artışı görürsünüz.

Aksiyon önerisi: Bugün önce 24-48 saatlik slow query log ve PHP-FPM metriklerini çıkarın; sonra OPCache + PHP-FPM değerlerini RAM’e uygun şekilde güncelleyip geri test edin. Son olarak MySQL buffer pool’u hedef veri setini cache’leyecek seviyeye taşıyın; lock/slow sorgu listesini tamamen temizleyene kadar tek tek iterasyon yapın.