Bir WordPress Sitesini Hızlandırmanın Sessiz Yolu
Tema ve görseller iyileştirildiği halde özellikle sepet, ödeme veya yönetim sayfaları yavaş kalıyorsa, sunucu üzerindeki dinamik istek yolunu inceleyin. PHP-FPM çalışanları, OPcache, WordPress nesne önbelleği ve MySQL farklı işleri üstlenir. Bu bileşenlerin ayarları kaynak kullanımını etkiler; ancak birinin değerini artırmak her darboğazı çözmez. Önce hangi isteğin nerede beklediğini ölçmek gerekir.
Bu rehber PHP-FPM eşzamanlılığını, derlenmiş PHP kodunun OPcache içinde tutulmasını, Redis ile kalıcı nesne önbelleğini ve MySQL sorgu davranışını birlikte ele alır. Örnek sayılar evrensel öneri değildir. Sunucunun toplam belleği, uygulamanın yoğun istekleri ve veri dayanıklılığı gereksinimleri üzerinden nasıl karar vereceğinizi ve değişiklikleri nasıl doğrulayacağınızı açıklar.
PHP-FPM: Sırayı Düzenleyen Sessiz Çalışanlar
PHP isteklerini kuyruktan sahneye çıkaran düzen
WordPress’in dinamik istekleri PHP çalıştırır; CDN veya sayfa önbelleğinden karşılanan bir istek ise PHP’ye hiç ulaşmayabilir. PHP-FPM kullanılan kurulumlarda havuz çalışanları gelen PHP isteklerini işler. Az çalışan kuyruk yaratabilir, fazla çalışan ise belleği ve CPU’yu tüketebilir. Önce sayfa önbelleği isabetleri ile gerçekten PHP’ye ulaşan trafiği ayırın; farklı PHP çalışma modellerinde aynı havuz ayarları bulunmayabilir.
Havuz dosyası kullanılan PHP sürümüne ve dağıtıma göre değişir. Yönetim paneli tarafından üretilen bir dosyayı elle değiştirmek yerine panelin desteklediği yolu kullanın. pm modu çalışanların sabit, dinamik veya isteğe bağlı yönetilmesini seçer. Çalışan sayısını sadece CPU çekirdeğine göre belirlemeyin: veritabanı, Redis, işletim sistemi, ortak OPcache belleği ve ani istekler için pay ayırın.
Kaynak bütçesine göre örnek havuz ayarı
Aşağıdaki dynamic havuz parçası bir açıklama örneğidir; 12 çalışan veya 60 saniyelik sonlandırma her site için uygun değildir. Sepet, ödeme, içe aktarma ve arka plan işleri gibi farklı akışları ölçün. Kullanıcı, grup, socket izinleri ve günlük dizinleri mevcut havuzun gereksinimlerine göre ayrıca yapılandırılmalıdır. Dosya yolundaki yıldız bir yer tutucudur; gerçek PHP sürümünün dosyasını seçin.
; /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
pm.max_children bu havuzdaki eşzamanlı istekleri sınırlar; birden fazla havuz varsa toplamlarını hesaba katın. pm.max_requests bir çalışanı belirtilen sayıda istekten sonra yeniler ve bazı uzun süreli bellek büyümelerini sınırlayabilir; sızıntının nedenini düzeltmez. request_slowlog_timeout tanı için geri iz üretirken request_terminate_timeout çalışanı sonlandırabilir. Sırf yavaşlığı gizlemek için süreyi daraltmayın; kesilen işlemlerin ödeme veya veri tutarlılığına etkisini değerlendirin.
Bellek, CPU ve ayarların karşılıklı sohbeti
Temsilî yoğunluk altında çalışan başına bellek dağılımını gözlemleyin; yalnız ortalama, ağır isteklerin tepe kullanımını gizleyebilir. Ortak belleği her süreç için tekrar saymamaya dikkat ederek PHP’ye ayırdığınız bütçeyi ve ek güvenlik payını hesaplayın. CPU doygunluğu, I/O beklemesi ve veritabanı gecikmesi de sınır koyar. Daha çok çalışan açmak aynı yavaş sorguya daha fazla eşzamanlı yük bindirebilir.
Önce mevcut kuyruk uzunluğunu, aktif çalışanları, yanıt süresinin p95/p99 değerlerini ve hata oranını kaydedin. FPM durum uç noktasını ve günlükleri herkese açmayın; yalnız yetkili izleme yolundan erişin. Kuyruk artarken CPU veya veritabanı zaten doygunsa önce istek başına işi azaltın. Kaynak payı varsa çalışan sayısını küçük adımlarla deneyip aynı yükte karşılaştırın; bir sonraki adım için ölçülebilir hedef ve geri dönüş eşiği belirleyin.
OPcache: Aynı Dosyayı İkinci Kez Derletmeme Sanatı
“Bir kere derle, tekrar kullan” mantığı
OPcache, PHP dosyalarının derlenmiş ara kodunu ortak bellekte tutarak tekrar ayrıştırma ve derleme işini azaltabilir. Tam HTML sayfasını veya sorgu sonucunu saklamaz. İlk erişimlerde önbellek ısınır; sonraki yarar kodun, CPU yükünün ve diğer beklemelerin payına bağlıdır. Uygulamanın yaptığı SQL veya dış API çağrısı yavaşsa OPcache bunu tek başına gidermez.
Ayarları web isteklerini işleyen PHP-FPM sürümünün INI yapılandırmasında kontrol edin; CLI farklı dosya ve önbellek kullanabilir. Değişikliğin kapsamına göre kontrollü yeniden yükleme veya yeniden başlatma gerekebilir. Aşağıdaki PHP 8 örneğinde bellek değerleri temsilîdir; FPM, Redis ve veritabanıyla toplam bütçeyi aşmamalıdır. Kod değişikliklerinin algılanmasını ve geri dönüşü gerçek yayın süreciyle sınayın.
; PHP 8 FPM icin ilgili INI dosyasi; kapasite degerleri ornektir
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=2
opcache.jit=disable
opcache.memory_consumption ortak önbellek için MB cinsinden bütçedir; dosya tablosu, doluluk, boşa ayrılan bellek ve yeniden başlama sayaçlarını birlikte izleyin. validate_timestamps açıkken revalidate_freq saniye cinsinden kontrol aralığını belirler; bu pencerede eski kod görülebilir. Kontrol aralığını artırmak yayın tutarlılığına bedel getirebilir. revalidate_freq=0 kontrolü kapatmaz; her istekte kontrol yapılmasını sağlar. validate_timestamps=0 ile otomatik zaman damgası doğrulamasını kapatırsanız kod değişiklikleri için açık bir geçersizleştirme/yeniden başlatma süreci gerekir. Web SAPI’sinin önbelleğini hedefleyin; yalnız CLI’de sıfırlama yapmanın FPM’i yenilediğini varsaymayın. Herkese açık bir sıfırlama betiği bırakmayın.
Ayar adları ve sürüm farkları için resmî OPcache yapılandırma belgelerini kullanın. JIT, derlenmiş dosya önbelleğinden ayrı bir özelliktir; bu örnekte kapalıdır. İş yükünüz için kanıt olmadan JIT veya daha büyük önbelleğin evrensel hız kazancı sağlayacağını varsaymayın.
Redis: Kalıcı Nesne Önbelleği ile WordPress’i Nefeslendir
Sorgu tekrarlarını hafızaya almanın pratik yolu
WordPress’in varsayılan nesne önbelleği bir isteğin ömrüyle sınırlıdır. Uyumlu bir Redis entegrasyonu, uygun nesneleri istekler arasında saklayabilir. Bu, nesne önbelleği API’sini kullanan tekrarları azaltır; her SQL sorgusunu otomatik önbelleğe almaz ve tam sayfa önbelleğiyle aynı şey değildir. Sepet, hesap ve ödeme içeriğinin kişiye özel olması, sayfa önbelleğinde açık istisnalar ve doğru anahtar ayrımı gerektirir.
Önce uyumlu istemci/eklenti ve gerekiyorsa object-cache.php drop-in dosyasının gerçekten etkin olduğunu doğrulayın. Hazırlık ortamında ürün güncellemesi, stok, kullanıcı ayrımı, sepet ve ödeme akışlarını sınayın. Aşağıdaki örnek aynı sunucudaki PHP için ayrılmış, yalnız yeniden üretilebilir önbellek tutan bir Redis hizmetini varsayar. Oturum, kuyruk veya başka birincil veri barındıran mevcut Redis’e bu kalıcılık ayarlarını uygulamayın. Paylaşımlı sunucuda loopback tüm yerel kullanıcıları ayırmaz; uygun ACL ve uygulama izinleri ayrıca gereklidir.
Debian/Ubuntu üzerinde paket uygunluğunu kontrol ettikten sonra kurulum örneği:
sudo apt update && sudo apt install redis-server
Yalnız bu uygulamaya ayrılmış Redis önbelleği için mevcut redis.conf içinde uyarlanacak parça:
bind 127.0.0.1 -::1
protected-mode yes
maxmemory 512mb
maxmemory-policy allkeys-lru
appendonly no
save ""
512 MB örnek sınırdır; Redis sürecinin toplam belleği ve diğer hizmetler için ek pay ayırın. Etkili yapılandırmayı, erişim izinlerini, hizmet günlüklerini ve uygulama bağlantısını kontrol ederek uygulayın. Uzak Redis için özel ağ, kaynak kısıtı, uygun ACL ve şifreli bağlantı desteğini tasarlayın; korumalı modu kapatıp internete açmayın.
allkeys-lru yaklaşık LRU seçimiyle herhangi bir anahtarı çıkarabilir; bu yüzden örnek hizmette silinemeyecek oturum veya iş kuyruğu verisi bulunmamalıdır. appendonly no ve save boş dizesi AOF/RDB kalıcılığını kapatır: yeniden başlatma önbelleği soğutur ve uygulama veriyi yeniden üretmelidir. “Kalıcı nesne önbelleği” istekler arasında kullanım demektir, zorunlu disk kalıcılığı demek değildir. AOF seçilen başka bir tasarımda fsync politikası, disk yükü ve kayıp toleransı ayrıca değerlendirilir; AOF tek başına sıfır kayıp garantisi vermez.
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.
Redis sürümünüzün resmî belgelerinde bellek, kalıcılık ve erişim seçeneklerini inceleyin. Mantıksal veritabanı numarası veya anahtar öneki bir güvenlik sınırı değildir; farklı siteler ve kiracılar için izinleri ve gerektiğinde ayrı hizmetleri planlayın. İsabet oranıyla birlikte gecikme, çıkarılan anahtarlar, hata sayısı ve soğuk önbelleğin veritabanına yükünü de ölçün.
MySQL İnce Ayarları: InnoDB’yi Rahatlat, Sorguları Sakinleştir
Önce fotoğrafı çek: yavaş sorgu günlüğü
MySQL tarafında yavaş sorgu günlüğü ve sorgu planları darboğazın yerini daraltabilir. Günlük tek başına sorumlu eklentiyi kesin olarak tanımlamaz; istek izleri ve uygulama bağlamıyla eşleştirin. Günlüğün yazılabildiğini, döndürüldüğünü ve sorgulardaki kişisel/gizli değerlere erişimin kısıtlandığını kontrol edin. Aşağıdaki parça MySQL 8.4 içindir; MariaDB’ye veya farklı sürüme doğrudan kopyalanmamalıdır. Bellek, bağlantı ve redo kapasiteleri yalnız örnektir.
# MySQL 8.4 option-file parcasi; yollar ve kapasiteler ornektir
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
innodb_buffer_pool_size = 2G
innodb_redo_log_capacity = 1G
innodb_flush_log_at_trx_commit = 1
max_connections = 200
# Yalniz destekleyen Unix platformunda, olcum sonrasi istege bagli:
# innodb_flush_method = O_DIRECT
# Binary log etkinse dayaniklilik politikasi kapsaminda:
sync_binlog = 1
Buffer pool sıklıkla kullanılan InnoDB veri ve indekslerini tutar. 2 GB değeri her sunucuda doğru değildir; bağlantı başına bellek, diğer MySQL alanları, PHP ve Redis için de yer bırakın. innodb_redo_log_capacity disk üzerindeki redo bütçesidir; eski innodb_log_file_size tarifini farklı sürümlere taşımayın veya redo dosyalarını elle silmeyin. Örnekte innodb_flush_log_at_trx_commit=1 korunur. Değer 2, her commit’te diske kalıcı yazmayı gevşetir ve sistem arızasında onaylanmış işlemleri kaybettirebilir; yaklaşık saniyelik flush bir kesin kayıp üst sınırı değildir. Sipariş verisi için bu bedeli sıradan hız ayarı olarak sunmayın. MySQL 8.4’te innodb_flush_method için Unix varsayılanı destekleniyorsa O_DIRECT, aksi halde fsync’tir; Windows varsayılanı unbuffered’dır. Bu nedenle örnek etkin bir O_DIRECT zorlamaz. Desteklenen Unix ortamında bu seçeneği değerlendirebilirsiniz; etkili değeri, dosya sistemi/depolama desteğini ve temsilî iş yükünde sonucu doğrulayın. O_DIRECT her depolama düzeninde daha hızlı değildir; O_DIRECT_NO_FSYNC ile aynı davranışı vermez.
Arama veya raporlama eklentilerinin sorgularını EXPLAIN ve temsilî veriyle inceleyin. WHERE veya JOIN içinde geçen her sütuna gelişigüzel indeks eklemeyin; birleşik indeks sırası, seçicilik, yazma yükü ve sorgu planı önemlidir. Hazırlık ortamında sorgu süresiyle birlikte ek disk ve güncelleme maliyetini ölçün. Uygun nesneler tekrar kullanılıyorsa önbellek yardımcı olabilir; düşük isabetli veya yanlış geçersizleştirilen önbellek ek yük ve eski veri üretebilir.
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ı.
TTL, güncel veri sunmak için tek başına yeterli değildir. Fiyat, stok veya izin değiştiğinde doğru anahtarların geçersizleştirilmesi gerekir; ödeme ve hesap akışlarını gerçek entegrasyonla test edin. Çok kısa TTL yeniden hesaplama yükünü, aynı anda biten çok sayıda anahtar ise ani veritabanı yükünü artırabilir. Sıklık, anahtar kapsamı ve invalidation davranışını birlikte değerlendirin.
Ölç, Test Et, Ufak Dokunuşlarla İlerle
Küçük adımların büyük etkisi
Her deneyde tek ana değişkeni değiştirin; aynı veri, benzer önbellek sıcaklığı ve temsilî yükte karşılaştırın. Hazırlık ortamındaki sepet ve ödeme testlerinde ödeme sağlayıcısının test ortamını kullanın; gerçek sipariş, e-posta veya üçüncü taraf işlemleri oluşmasını engelleyin. Önbelleği ısıtmak için gerçek satın alma işlemlerini tekrar çalıştırmayın. Yanıt süresinin p95/p99 değerlerini, hata oranını, kuyrukları ve bellek tepesini kaydedin. Sadece önbellek isabet oranı veya ortalama süre iyi diye ödeme doğruluğunu ve kuyruk gecikmesini gözden kaçırmayın. Hedef iyileşme görülmezse ya da hata artarsa önceki yapılandırmaya dönün.
Ağ protokolü de toplam yanıt süresinin bir parçasıdır. HTTP/3 protokolünün performansa etkileri ağ tarafını değerlendirmenize yardımcı olabilir. HTTP/3 yavaş bir SQL sorgusunu düzeltmez; istemci, ağ ve destek koşulları altında uçtan uca ölçüm yapın.
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.
Varsayımsal Senaryo: Kampanya Trafiğinde Yavaşlayan Bir Mağaza
Darboğazı ölçüp değişikliği doğrulamak
Varsayımsal bir mağazada ana sayfa hızlı, kampanya döneminde ödeme akışı yavaş olsun. Önce PHP’ye ulaşan istekleri, kuyrukları ve sorgu sürelerini kaydedin. Bir kampanya eklentisinin sorgusu baskın görünürse temsilî veriyle planını inceleyin; uygun indeks veya sorgu değişikliğini hazırlık ortamında sınayın. Bu bir müşteri sonucu veya belirli hız kazancı iddiası değildir.
Kaynak payı kaldığı halde kuyruk varsa FPM çalışan sınırını kontrollü değiştirebilirsiniz. OPcache doluluk göstergeleri gerektiriyorsa alanını değerlendirin; Redis yalnız uygun tekrarlar için ve doğruluk testleriyle eklenmelidir. Her değişiklikten sonra aynı kampanya yükünü tekrar uygulayın. Daha kısa yanıt süresinin yanında stok, sipariş, oturum ayrımı ve hata oranının da beklenen biçimde kaldığını doğrulayın.
Deney kaydı; önceki ayarı, değişiklik gerekçesini, kullanılan yükü, sonuçları ve geri dönüş adımını içermelidir. Birden fazla bileşeni aynı anda değiştirirseniz hangi etkinin nereden geldiğini ayırmak zorlaşır. Kapasite yetersizliği ölçümle doğrulanıyorsa sunucuyu büyütmek veya hizmetleri ayırmak da seçenekler arasındadır.
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.
Başlangıç ölçümünü ve yapılandırmayı saklayın; değişiklikten sonra temel kullanıcı akışlarını ve kaynak kullanımını kontrol edin. Yeni sürümde önbellek temizleme/ısınma sırasını ve geri dönüş planını deneyin. Desteklenen sürümleri izlemek, anlamlı uyarılar almak ve trafik değiştiğinde kapasite hesabını yenilemek, tek seferlik ayar listesinden daha kalıcı bir çalışma düzeni sağlar.
