WordPress için Sunucu Tarafı Optimizasyon: PHP-FPM, OPcache, Redis ve MySQL ile Neyi, Ne Zaman, Nasıl Ayarlamalısın?

Bir WordPress Sitesini Hızlandırmanın Sessiz Yolu: Sunucu Tarafı Ayarlar

Hiç şöyle oldu mu: Tema güncel, eklentiler ayıklanmış, görseller sıkıştırılmış… ama site hâlâ o beklediğin tıkır tıkır hızda açılmıyor. Ben de bir dönem buna takılıp kalmıştım. Ön yüzü cilalamaktan yorulunca kafayı sunucu tarafına çevirdim. Meğer asıl sessiz kahramanlar oradaymış: PHP-FPM, OPcache, Redis ve MySQL ayarları. Çoğu zaman grafikte bir çizgi değil, kasada gerçek bir nefes alma yaratıyorlar.

Bu yazıda adım adım, paniklemeden ve jargon boğulmadan şu dört parçayı elden geçireceğiz. Neyi, neden yaptığımızı örneklerle anlatacağım. Mesela “pm.max_children” nedir dediğinde bir tabloya bakmak zorunda kalmayacaksın, kafanda canlanacak. OPcache’i açıp bırakmakla bitmediğini, Redis’i zorla değil doğru yerde devreye sokman gerektiğini ve MySQL’in küçücük bir ayarıyla rastgele gecikmeleri nasıl sildiğimi kendimce bir hikâye gibi paylaşacağım. Hadi omuzdan omuza bakalım, beraber ayar çekelim.

PHP-FPM: Sırayı Düzenleyen Sessiz Çalışanlar

PHP isteklerini kuyruktan sahneye çıkaran düzen

WordPress, dinamik bir yapı. Her tıklama yeni bir PHP yorumu demek. PHP-FPM buradaki trafiği yöneten bir sahne amiri gibi çalışıyor. Havuz dediğimiz yapı, bu istekleri karşılayan çalışanları yönetiyor. Çok az çalışan koyarsan kuyruk uzuyor, çok fazla koyarsan sunucuyu zorlayıp her şeyi ağırlaştırıyorsun. Tam burada küçük, bilinçli dokunuşlar devreye giriyor.

İlk bakacağın yer havuz ayarları. Genelde “www.conf” gibi bir dosyada durur. “pm” modu, kaç çalışan açılacağını ve nasıl yönetileceğini belirliyor. Basit bir kural: bellek hesabını kabaca yaptıktan sonra makul bir çocuk sayısı seç. Kafamızda somutlaştıralım; varsa 4 çekirdek ve sınırlı RAM, ilk adımda mütevazı başlamak doğru olur. Sonra gerçek trafiğe göre yükseltirsin.

Başlangıç için güvenli bir havuz tarifi

Örnek bir havuz ayarı görelim. Sadece kopyalayıp yapıştırmak için değil; neyin neden değiştiğini kavramak için göz atacağız. Küçük ve orta ölçekli WordPress siteleri için çekirdek ve bellek hesabına göre şu tarz bir başlangıç tatlı bir denge yaratır. Çok düşük veya çok yüksek değerlerden kaçınmak çoğu zaman en akıllı başlangıç oluyor.

; /etc/php/*/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 12
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

Burada “pm.max_children” toplam eşzamanlı PHP süreçlerini sınırlar. Bellek tüketimini izleyerek artırıp azaltabilirsin. “pm.max_requests” uzun yaşayan süreçlerin şişmesini engeller. “slowlog” ise gizli yavaşları ortaya çıkarır. Ben ilk günlerde slowlog’a bakmadan karar vermem, çünkü çoğu problem orada sessizce yazılı durur.

Bellek, CPU ve ayarların karşılıklı sohbeti

“Kaç çocuk açsam?” sorusunun cevabı RAM ve CPU ile aynı masada aranır. PHP süreçlerinin ortalama ne kadar RAM yediğini gözlemleyip toplam belleğe göre üst sınır belirlemek iyi bir pratik. CPU tarafı da önemli: süreçleri çok artırınca bağlam değişimi artıyor, bu da verim düşürüyor. Yani bazen sayıyı artırmak yerine OPcache ve sorgu tarafındaki iyileştirmelerle istek başına süreyi kısaltmak daha iyi sonuç veriyor.

Benim rutinim basit: önce mevcut yükte yavaş logu açarım, kuyruk oluşuyorsa çocuk sayısını adım adım artırırım. Belirli bir noktada iyileşme temasını kaybedince durup düşünürüm; bazen sorun CPU değil, disk veya veritabanıdır. PHP-FPM tek başına kahraman değildir, ama doğru ayarlarla oyunu taşır.

OPcache: Aynı Dosyayı İkinci Kez Derletmeme Sanatı

“Bir kere derle, tekrar kullan” mantığı

WordPress’in temel dosyaları sürekli çalışır. Her istekte bu dosyaları baştan derlemek yerine OPcache ile hafızada tutmak, zamandan ve enerjiden tasarruf ettirir. Etkisini bazen anında hissedersin: ilk istekler ısınır, arkası yağ gibi akar. “Açtım bitti” diye düşünmek cazip, ancak ufak ayarlarla çok daha dengeli bir sonuç alırsın.

OPcache ayarları genellikle php.ini’de yer alır. Uygularken her değişiklikten sonra PHP-FPM’i nazikçe yeniden başlatmayı unutma. Aşağıdaki ayarlar sağduyulu bir başlangıç noktası. Panik yok; sayılar sabit değil, izleyerek değiştirirsin.

; php.ini
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.jit=0

“opcache.memory_consumption” OPcache için ayrılan bellek. “max_accelerated_files” çok düşük olursa dosya tablosu dolar, bu da beklenmedik yavaşlıklar yaratır. “validate_timestamps” ve “revalidate_freq” ise kod değişikliklerini ne kadar hızlı fark edeceğini belirler. Geliştirme ortamında süreyi kısaltır, üretimde biraz artırırsın. Bu küçük denge, gereksiz dosya kontrolünü azaltır.

Detayları kurcalamak istersen resmi OPcache ayar referansına göz atmak iyi olur. Ben ihtiyaç duyduğumda OPcache yapılandırma belgelerini kontrol eder, ama önce ölçüme bakarım. Çünkü ölçmeden yapılan her ayar, tahmindir.

Redis: Kalıcı Nesne Önbelleği ile WordPress’i Nefeslendir

Sorgu tekrarlarını hafızaya almanın pratik yolu

WordPress, aynı verileri defalarca çekmeye meyilli. Özellikle eklentiler çoğaldıkça bu tekrarlar artıyor. Redis burada bize “kalıcı nesne önbelleği” olarak yardımcı olur. Basitçe söyleyeyim: aynı şey için her seferinde veritabanına gitmek yerine, RAM’den servis edersin. Ve bu, trafiğin yükseldiği anlarda siteyi sakinleştirir.

Kurulum basit. Sunucuna Redis’i kurar, hizmeti başlatır ve WordPress tarafında bir nesne önbellek eklentisi ile bağlarsın. Ben üretime geçmeden önce bir sahne ortamında denemeyi severim. Çünkü bazı eklentilerle anahtar isimleri çakışabilir veya TTL ayarları fazla agresif olabilir. Küçük bir test turu, sonradan yaşayacağın baş ağrısını alır.

# Debian/Ubuntu örneği
sudo apt update && sudo apt install redis-server -y

# /etc/redis/redis.conf içinde birkaç pratik dokunuş
databases 16
maxmemory 512mb
maxmemory-policy allkeys-lru
appendonly yes

“maxmemory-policy” seçimleri davranışı değiştirir. LRU (en az kullanılanı çıkar) genelde iyi bir başlangıç. “appendonly” ise veri kalıcılığı sağlar; küçük bir performans maliyeti vardır ama çoğu senaryoda kabul edilebilir. WordPress eklentisi tarafında ise anahtarların TTL ayarlarına dikkat etmek, özellikle sık değişen sayfalarda taze içerik sunmak için önemlidir. Gereksiz uzun ömür, güncellemelerde kafa karıştırır.

Redis’in WordPress performansını nasıl hızlandırdığını daha rahat sindirmek istersen, bizim hazırladığımız Redis’in hosting performansına etkisini anlaşılır örneklerle anlatan rehbere göz atmanı öneririm. Orada seçtiğin stratejinin sitenin türüne göre nasıl değiştiğini daha akıcı bir dille bulacaksın.

Kurcalamak hoşuna gidiyorsa, Redis tarafında kalıcılık ve bellek politikaları için Redis belgelerinde önerilen kalıcı yapılandırmalar bölümüne bakman da iyi olur. Ancak yine altını çizeyim: ölç, izle, küçük adımlarla ilerle. Bir defalık “açtım bitti” yerine ritimli bir bakım, Redis’i gerçek bir performans dostuna çevirir.

MySQL İnce Ayarları: InnoDB’yi Rahatlat, Sorguları Sakinleştir

Önce fotoğrafı çek: yavaş sorgu günlüğü

MySQL tarafında ilk işim her zaman yavaş sorgu günlüğünü açmak olur. Sorunu görmeden ayar yapmak, karanlıkta vida sıkmaya benziyor. Yavaş sorgu günlüğü, hangi eklenti veya sayfanın işi ağırdan aldığını fısıldar. Oradan aldığın ipuçlarıyla ya sorguyu iyileştirirsin ya da önbellek katmanlarını daha bilinçli ayarlarsın. Sonrasında genel InnoDB ayarlarıyla zemini sağlamlaştırırsın.

-- my.cnf ya da mysqld.cnf örneği
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 200

“innodb_buffer_pool_size” en kritik değerdir. Sıklıkla erişilen verileri RAM’de tutar. Veritabanı boyutunun tamamını girmeye kalkma, toplam RAM ve diğer servislerle ortak yaşam kur. “innodb_flush_log_at_trx_commit” değerini 2 yapmak, bir nebze performans sağlar; veri kaybı toleransı olmayan ortamlarda bunu tekrar düşün. Bu ayarların hepsi birer kaldıraç; dengeyi senin iş yükün belirler.

WordPress’te sık gördüğüm bir durum var: arama eklentileri veya raporlama araçları beklenmedik sorgular üretir. Yavaş sorgu günlüğünde bunları yakaladığında bazen tek bir indeks eklemek, gecikmeyi dramatik biçimde azaltır. Bu hep hoşuma gider; küçük bir dokunuş, büyük bir nefes. Eğer sorgu iyileştirmesi mümkün değilse, Redis ile o sayfanın dinamik parçalarını daha akıllı önbelleğe almak çoğu zaman işe yarar.

InnoDB’nin çalışma mantığını basitçe anlamak istersen, resmî dokümantasyondaki InnoDB buffer pool’un mantığına dair açıklamalara göz atabilirsin. Ama tekrar söyleyeyim: önce ölç, sonra ayarla. Aksi halde bir yerde hızlanırken başka yerde gizli bir fren yaratabilirsin.

Bağlantı havuzu, TTL ve gerçek trafik

Uygulama katmanında bir bağlantı havuzu kullanıyorsan, MySQL tarafındaki “max_connections” değerini uçuk noktalara taşımak zorunda değilsin. Önce havuzun davranışını anla, ardından veritabanını ona göre ayarla. Sırf “bağlantı hatası” gördüm diye sınırı yükseltmek bazen ilaç değil, yeni bir hastalık yaratır. Gerçek kullanımın ritmine kulak vermek daha sağlıklı.

WordPress tarafında kısa TTL’ler, sık güncellenen sayfalar için taze içerik sağlar. Ama her şeyi kısa tutmak da belleği hırpalar. Dengeyi bulmanın yolu basit: en çok trafik alan sayfayı izle, değişiklikleri ne kadar sıklıkta yapıyorsun bak, sonra TTL’i buna göre ayarla. Bu üçlü, seni gereksiz karmaşadan korur.

Ölç, Test Et, Ufak Dokunuşlarla İlerle

Küçük adımların büyük etkisi

Benim için en verimli yöntem, bir şeyi değiştirmek ve etkisini kısa bir pencerede izlemek oldu. OPcache belleğini iki katına çıkardığında zaman grafiğinde eğri nasıl kıpırdıyor, Redis TTL’i uzatınca geri dönüşler nasıl değişiyor, PHP-FPM çocuk sayısını artırınca CPU nasıl tepki veriyor… bunları görmeden kalıcı karar vermem. Sunucu tarafı optimizasyon bir defalık proje değil, alışkanlık haline gelince meyvesini veriyor.

Sunucu seviyesinde ek tüyolar da var. HTTP katmanında yeni nesil protokollerin bazen gündüz vakti açan güneş gibi etkisi oluyor. İlgini çekerse, HTTP/3 protokolünün site açılışlarına etkisi üzerine hazırladığımız yazı, ağ tarafındaki küçük güncellemelerin hissedilir sonuçlarını örnekliyor. Uygulamayı güçlendirdikten sonra, ağın da nefeslenmesini izlemek güzel.

Ve evet, web sunucusu seçimi de bu hikâyenin parçası. Bu konunun derinlerine meraklıysan, LiteSpeed ve Apache web sunucuları arasındaki farkların tartışıldığı yazımıza göz atabilirsin. Burada doğrudan bir “en iyi” yok; senin trafik şeklin, eklenti alışkanlıkların ve sunucu kaynakların en doğru kararı verir.

Güvenlik ve Dayanıklılık: Performansın Sessiz Eşlikçisi

Güvenlik açık olduğunda hız uzun sürmez

Performansı konuştuk ama güvenlik olmadan bu kazanımlar kalıcı olmaz. Basit bir DDoS bile bütün emekleri kısa süreliğine etkileyebilir. Bu yüzden, ağ katmanında temel korumaları aktif tutmak ve muhtemel saldırı yüzeylerini daraltmak performansın da sigortasıdır. Detaylı bir genel bakış istersen, DDoS saldırıları ve korunma yöntemleri yazımızda pratik öneriler bulabilirsin.

Sunucu güvenliğinin günlük bakımı da gerçekten fark yaratır. Servislerin gereksiz açık portlarını kapatmak, logları düzenli okumak ve güncellemeleri ertelemeden kurmak… Bu basit alışkanlıklar performans yatırımlarını korur. Adım adım ilerlemek istersen, VPS sunucu güvenliğini pratik ve ölçeklenebilir şekilde ele alan şu rehberi de faydalı bulacaksın.

Bazen de performans problemi sanıp uğraştığımız şey, aslında güvenlikten doğan bir yük oluyor. Orada yapılacak doğru bir kural düzenlemesi veya hız sınırlaması, sistemin nefesini açıyor. O yüzden teşhis kısmını ihmal etme; yavaşlık her zaman sadece kaynak yetersizliği değildir.

Gerçek Bir Senaryo: Küçük Bir E-Ticaret Sitesinin Sessiz Dönüşümü

Kırmızı çizgiden yeşil alana

Bir e-ticaret sitesinde başıma geleni anlatayım. Trafik normal, ama kampanya saatlerinde site birden dalgalanıyordu. Önce ön yüzü kurcaladık, bir şey çıkmadı. Yavaş sorgu günlüğünü açtım ve kampanya sayfasındaki bir eklentinin beklenmedik şekilde karmaşık sorgular ürettiğini gördüm. Bir indeks ekledik, ağır sorguyu hafifleten küçük bir düzenleme yaptık.

Ardından PHP-FPM tarafında “pm.max_children” değerini bir tık yükselttik. OPcache dosya tablosunu genişlettim, Redis’i devreye alıp TTL’leri kampanya anlarına uygun şekilde ayarladım. Sonuç, daha stabil bir yük eğrisi oldu. Dakika başına istek arttığında bile kuyruk yerine akış gördük. Büyü yok, sadece disiplinli küçük adımlar.

Analizden sonra şunu fark ettim: her değişikliğin izini sürdüğümüzde, nerede durmamız gerektiğini daha net görüyoruz. Çünkü bazen “daha fazla” değil “tam yerinde” olan kazanıyor. Bu hikâyenin en güzel yanı da bu; bir ayarı köküne kadar açmak yerine, doğru noktada bırakmayı öğreniyorsun.

Kapanış: Ayar Değil Alışkanlık

Bir defalık sihir değil, düzenli bakım

Sunucu tarafı optimizasyonu bir kere yapıp kenara koymak yerine, düzenli bir bakım gibi düşün. PHP-FPM havuzunu izleyip küçük düzeltmeler yapmak, OPcache’in belleğini dolmadan önce rahatlatmak, Redis anahtarlarını sağlıklı yaşatmak, MySQL’in yavaşlarını zamanında yakalamak… Bu dört adım aslında bir rutin. Uyguladıkça daha iyi tanır, daha az eforla daha çok verim alırsın.

Son bir ipucu: her değişiklikten sonra not al. Hangi değeri ne zaman arttırdın, niye geri aldın, hangi grafikte neyi gördün… Bu küçük notlar, iki ay sonra altın değerine dönüşüyor. Umarım bu yazı, adım atarken elini hafifleten bir rehber olmuştur. Bir sorunda takılırsan, hikâyeyi ve ölçümü paylaş; birlikte yorumlamak her zaman daha kolay. Bir dahaki yazıda, belki de ağ katmanında küçük bir dokunuşun koca bir hissiyatı nasıl değiştirdiğini konuşuruz.