Puan
18
Çözümler
0
- Katılım
- 3 Kas 2025
- Mesajlar
- 99
- Tepkime puanı
- 0
WordPress Veritabanı Optimizasyonu: Autoload, Revizyonlar ve Yavaş Sorgular İçin Rehber
WordPress siteniz yavaşladığında veritabanını temizlemek işe yarayabilir. Ancak bütün revizyonları silmek veya “tabloları optimize et” düğmesine basmak, her performans sorununu çözmez.Büyük bir veritabanı doğru sorgularla hızlı çalışabilir. Küçük bir veritabanı ise kötü yazılmış bir eklenti, gereksiz sorgular veya yetersiz sunucu kaynakları nedeniyle yavaşlayabilir.
Bu nedenle veritabanı optimizasyonunu üç iş olarak düşünmek daha yararlıdır: gereksiz veriyi azaltmak, uygulamanın veritabanını nasıl kullandığını incelemek ve ölçülen darboğazı gidermek.
Veritabanı Neden Büyür, Ne Zaman Sorun Oluşturur?
WordPress; yazıları, kullanıcıları, yorumları ve ayarları veritabanında tutar. Eklentiler de kendi tablolarını veya mevcut tablolarda yeni kayıtlar oluşturabilir.Zaman içinde büyümeye neden olan başlıca veriler şunlardır:
- Yazı ve sayfa revizyonları.
- Çöp kutusundaki içerikler ve spam yorumlar.
- Geçici önbellek kayıtları.
- Eklenti günlükleri ve işlem geçmişleri.
- Kullanılmayan uygulama ayarları.
- Büyük miktarda ürün, sipariş veya içerik metaverisi.
Önce büyüyen tablonun ne tuttuğunu öğrenin. Ardından hangi verinin saklanması gerektiğine karar verin.
İlk Adım: Ölçüm ve Yedek
İşleme başlamadan önce mevcut durumu kaydedin. Böylece değişikliğin yararlı olup olmadığını karşılaştırabilirsiniz.| Ölçüm | Ne anlatır? |
|---|---|
| Veritabanı ve tablo boyutları | Hangi veri grubunun büyüdüğünü |
| Toplam sorgu süresi | Sayfa üretiminde veritabanına harcanan zamanı |
| Yavaş ve tekrarlanan sorgular | Uygulama tarafındaki olası darboğazları |
| Autoload boyutu | Otomatik yüklenen ayarların hacmini |
| CPU, RAM ve disk kullanımı | Sunucu kaynaklarının durumunu |
Karşılaştırmayı aynı sayfalarda ve benzer koşullarda yapın. Önbellekten sunulan ana sayfa ile oturum açılmış yönetici panelini aynı ölçüm gibi değerlendirmeyin.
Ardından veritabanı yedeğini alın. WP-CLI erişiminiz varsa örnek komut:
wp db export /home/hesap/yedekler/veritabani-oncesi.sqlYolu kendi hesabınıza göre değiştirin ve klasörün mevcut olduğundan emin olun. SQL yedeğini ziyaretçilerin erişebileceği web klasöründe bırakmayın.
wp db export, veritabanını SQL dosyasına aktarır. Site dosyalarını da değiştirecekseniz onların ayrıca yedeklenmesi gerekir.Kritik bir sitede yedeğin deneme ortamına geri yüklenebildiğini doğrulamak, yalnızca dosyanın oluştuğunu görmekten daha güçlü bir kontroldür.
Autoload Nedir ve Neden İncelenmeli?
WordPress’in options tablosunda uygulama ayarları bulunur. Autoload, bazı ayarların gerektiğinde tek tek sorgulanmak yerine topluca yüklenmesini sağlar.Bu mekanizma faydalıdır. Sorun, ihtiyaç duyulmayan büyük veri kümelerinin de otomatik yüklenmesidir.
Güncel WordPress’te autoload kontrolü yalnızca
yes değerine dayanmaz. Varsayılan olarak şu değerler otomatik yükleme kapsamındadır:
Kod:
yes
on
auto-on
autoWHERE autoload = 'yes' kullanan eski sorgular toplamı eksik gösterebilir.Autoload boyutu nasıl kontrol edilir?
Önce Araçlar > Site Sağlığı ekranını inceleyin. WordPress’in varsayılan autoload uyarı eşiği 800.000 bayttır. Bu, incelenmesi gereken bir durumu gösterir; tek başına sitenin yavaşlık nedenini kanıtlamaz.phpMyAdmin üzerinden toplam boyutu görmek için şu salt okunur sorguyu kullanabilirsiniz:
Kod:
SELECT
SUM(OCTET_LENGTH(option_value)) AS toplam_bayt
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
Kod:
SELECT
option_name,
OCTET_LENGTH(option_value) AS boyut_bayt,
autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY boyut_bayt DESC
LIMIT 20;wp_options adını değiştirin. Bu sorgular WordPress’in varsayılan autoload değerlerini esas alır; özel kodla değiştirilmiş davranışlar ayrıca değerlendirilmelidir.Büyük bir ayar kaydı bulduğunuzda ne yapmalısınız?
Önce kaydın hangi eklentiye veya özelliğe ait olduğunu belirleyin. Büyük olması, silinebileceği anlamına gelmez.Eklentinin kendi temizleme seçeneği, güncellemesi veya geliştiricinin önerdiği yöntem varsa onu kullanın. Bir ayarın autoload özelliğini kapatmak, gerektiğinde ayrı sorguyla okunmasına yol açabilir; bu da otomatik olarak hız kazancı demek değildir.
Tanımadığınız kayıtlarda toplu silme veya bütün autoload değerlerini kapatma işlemi uygulamayın.
Transient Temizliği: Geçici Önbelleği Doğru Anlamak
Transient, belirli süre saklanması amaçlanan geçici veridir. Örneğin bir eklenti dış servisten aldığı yanıtı transient olarak önbelleğe alabilir.Süresi dolmuş bütün transient’ler her sayfa isteğinde yüklenmez. Ayrıca WordPress’in süresi dolan kayıtlar için temizleme mekanizmaları vardır. Birikme görüyorsanız zamanlanmış görevlerin çalışıp çalışmadığını da kontrol edin.
WP-CLI ile süresi dolmuş transient’leri temizlemek için:
wp transient delete --expiredBu komut yalnızca süresi dolmuş kayıtları hedefler.
Bütün transient’leri silmek ise önbelleğin yeniden oluşturulmasına ve bazı dış servis isteklerinin tekrarlanmasına neden olabilir. Bu yüzden toplu temizliği rutin bir hızlandırma yöntemi olarak kullanmayın.
Redis veya Memcached gibi kalıcı nesne önbelleği etkinse transient’ler veritabanı yerine bu sistemde tutulabilir. Temizliği, sitenin kullandığı önbellek yapısına göre değerlendirin.
Revizyonları Sınırlayın, İçerik Geçmişini Planlayın
Revizyonlar, yazıların önceki sürümlerini saklar. İçerik üretimi yoğun sitelerde önemli miktarda kayıt oluşabilir.Gelecekte tutulacak revizyon sayısını sınırlandırmak için
wp-config.php dosyasına şu satır eklenebilir:define( 'WP_POST_REVISIONS', 5 );Aynı sabit zaten tanımlanmışsa mevcut değeri düzenleyin. Satır, WordPress yüklenmeden önce bulunmalıdır; genellikle dosyadaki “düzenlemeyi burada bırakın” açıklamasının üstüne yerleştirilir.
Bu ayarı eklemek, mevcut bütün eski revizyonları anında temizlemez. Eski birikim için ayrıca kontrollü bakım gerekir.
Temizlikten önce editörlerin hangi geçmişe ihtiyaç duyduğunu belirleyin. Doğrudan SQL ile kayıt silmek yerine WordPress’in veri ilişkilerini dikkate alan bir araç veya yöntem kullanın.
Çöp, Spam ve Eklenti Verilerini İnceleyin
Veritabanı bakımında şu grupları ayrı değerlendirin:| Veri grubu | Uygun yaklaşım |
|---|---|
| Spam yorumlar | Listeyi kontrol edip temizlemek |
| Çöp kutusundaki içerik | Geri yükleme ihtiyacını değerlendirmek |
| Eklenti günlükleri | Eklentinin saklama süresini ayarlamak |
| Eski görev kayıtları | İlgili eklentinin bakım aracını kullanmak |
| Kullanılmayan tablolar | Sahibini ve bağımlılıklarını doğrulamak |
Bir eklentinin kaldırılması, bıraktığı her verinin işe yaramaz olduğu anlamına gelmez. Yeniden kullanım, başka bir entegrasyon veya ortak bir bileşen söz konusu olabilir.
Özellikle görev tablolarında bekleyen işlemler ile tamamlanmış işlem geçmişini karıştırmayın. Bekleyen bir görevi silmek, zamanlanmış işlemin yapılmasını engelleyebilir.
OPTIMIZE TABLE Ne İşe Yarar?
OPTIMIZE TABLE, tablo ve indekslerin fiziksel düzenini yeniden oluşturabilir. Büyük miktarda veri silindikten sonra alan kazanmak veya belirli depolama sorunlarını azaltmak için yararlı olabilir.InnoDB tablolarında işlem genellikle tabloyu yeniden oluşturma ve istatistikleri güncelleme biçiminde yürür. Çıktıda şu mesaj görülebilir:
Table does not support optimize, doing recreate + analyze insteadBu mesajın ardından başarılı sonuç gelebilir. Ancak bütün hata ve uyarıları normal kabul etmeyin; nihai durumu kontrol edin.
Belirli bir tablo için örnek:
OPTIMIZE TABLE wp_options;WP-CLI ile veritabanında daha geniş kapsamlı işlem:
wp db optimizeBu komut MySQL’in bakım aracını kullanır; gereksiz içerikleri veya revizyonları seçerek silmez.
Büyük tablolarda işlem disk ve I/O tüketebilir, kilit beklemelerine yol açabilir. InnoDB’de boş alanın bir kısmı sonraki işlemlerde yeniden kullanılabilir; görünen her “overhead” değeri acil müdahale gerektirmez.
Bu nedenle bütün tabloları her ay otomatik optimize etmek yerine, gereksinimi doğrulayın ve işlemi uygun bakım saatinde yapın.
Asıl Sorun Yavaş Sorguysa Temizlik Yetmez
Bir eklenti aynı sayfada yüzlerce sorgu çalıştırıyorsa veya büyük bir tabloyu verimsiz tarıyorsa, revizyon temizliği sınırlı fayda sağlayabilir.Query Monitor; sorgu sürelerini, tekrar eden sorguları ve bunların ilişkili olduğu bileşenleri incelemek için kullanılabilir.
Daha ayrıntılı incelemede:
- Yavaş sorgu günlüklerini kontrol edin.
- Sorgunun hangi ekran veya işlemde oluştuğunu belirleyin.
EXPLAINile yürütme planını inceleyin.- Uygun indeks veya sorgu değişikliğini test edin.
- Sonucu aynı koşullarda tekrar ölçün.
Redis ve Sayfa Önbelleği Nerede Devreye Girer?
Kalıcı nesne önbelleği, WordPress’in uygun veri ve nesneleri istekler arasında yeniden kullanmasını sağlayabilir. Ancak Redis’in kurulmuş olması, bütün SQL sorgularının sonuçlarının kendiliğinden önbelleğe alındığı anlamına gelmez.WordPress tarafında çalışan entegrasyon ve uygulamanın önbelleği kullanma biçimi önemlidir.
Sayfa önbelleği ise uygun ziyaretçilere önceden üretilmiş yanıt sunarak PHP ve veritabanı işini azaltabilir. Üye alanı, sepet ve ödeme sayfaları gibi kişiselleştirilmiş bölümler farklı kurallar gerektirir.
Sunucu tarafında da
innodb_buffer_pool_size gibi ayarlar önemlidir. Aynı sunucuda PHP, web sunucusu ve e-posta hizmetleri çalışıyorsa RAM’in sabit bir yüzdesini veritabanına ayırmak yerine toplam bellek ihtiyacını değerlendirin.Bakım Sıklığını Sitenin İhtiyacına Göre Belirleyin
Her site için aynı bakım takvimi uygun değildir. Az güncellenen bir tanıtım sitesiyle yoğun sipariş alan bir mağazanın ihtiyaçları farklıdır.| İşlem | Ne zaman yapılmalı? |
|---|---|
| Yedekleme | Kabul edilebilir veri kaybı süresine göre |
| Çöp ve günlük temizliği | Saklama politikası ve büyüme hızına göre |
| Autoload incelemesi | Uyarı, performans sorunu veya büyük eklenti değişikliği sonrası |
| Yavaş sorgu analizi | Yavaşlayan ekran veya artan kaynak kullanımı görüldüğünde |
| Tablo optimizasyonu | Ölçüm ve bakım ihtiyacı doğrulandığında |
Bakım sonrası ana sayfa, yönetici paneli, arama, form ve varsa sipariş akışını test edin. Veritabanının küçülmesiyle sorgu sürelerinin kısalmasını ayrı sonuçlar olarak değerlendirin.
