Query Monitor ile Yavaş Eklenti ve Sorgu Nasıl Bulunur?

Query Monitor'ü kurup yavaş sayfayı yönetici olarak açtığınızda yönetim çubuğunda dört sayı belirir: sayfa üretim süresi, en yüksek bellek kullanımı, toplam sorgu süresi ve sorgu sayısı. Bu sayılara tıklayıp açılan panelde önce Queries by Component ekranına bakın. Burada sorgular eklenti, tema ve çekirdek bazında toplanır ve toplam süreye göre sıralanır, en üstteki bileşen ilk şüphelinizdir. Ardından Slow Queries (varsayılan eşik 0,05 saniye), Duplicate Queries ve HTTP API Calls panellerinde o bileşenin ne yaptığını doğrulayın. AJAX ve REST istekleri için veriler yanıt başlıklarında gelir. İş bitince eklentiyi devre dışı bırakın.

Kurulum ve yönetim çubuğundaki ilk okuma

Query Monitor sıradan bir eklenti gibi kurulur: Eklentiler menüsünden yeni eklenti ekleme ekranına gidin, "Query Monitor" diye arayın, kurup etkinleştirin. WordPress.org'daki eklenti sayfasına göre güncel sürüm 4.1.1, en az WordPress 6.3 ve PHP 7.4 istiyor. Çıktıyı varsayılan olarak yalnız tek siteli kurulumlarda yöneticiler, Multisite'ta süper yöneticiler görür. Ziyaretçileriniz hiçbir şey fark etmez.

Etkinleştirdikten sonra yavaş olduğunu düşündüğünüz sayfayı açın ve yönetim çubuğundaki dört sayıyı not edin. Burada bir ayrıntı sonuçları baştan belirler. Oturum açmış bir yönetici olarak gezdiğiniz için sayfa önbelleği devre dışıdır, gördüğünüz süre sayfanın PHP tarafında sıfırdan üretilme süresidir. Bu tam da istediğimiz şey, çünkü eklenti ve sorgu yükü ancak önbelleksiz üretimde görünür. Ama ziyaretçinin yaşadığı süreyle karıştırmayın, ziyaretçi önbellekten sunulan kopyayı alıyor olabilir.

Aynı sayfayı üç dört kez yenileyin ve ilk ölçümü saymayın. İlk istekte nesne önbelleği, OPcache ve veritabanının kendi tamponları henüz ısınmamıştır, ikinci ve sonraki istekler daha gerçekçi bir taban verir. Genel yavaşlık nedenlerini WordPress sitesinin neden yavaş açıldığını ölçerek ayırma rehberinde topladık. Burada amaç, şüpheyi bir eklentiye ya da sorguya kadar daraltmak.

Süre nereye gidiyor? Overview ve Timeline

Çubuktaki sayılardan birine tıkladığınızda panel Overview ile açılır. Önce iki oranı kafanızda kurun. Toplam sorgu süresi, sayfa üretim süresinin büyük kısmını mı tutuyor? Diyelim ki sayfa 2,4 saniyede üretiliyor ve sorgular toplam 1,9 saniye. O zaman aradığınız şey veritabanındadır ve sorgu panelleri cevabı verecek. Sorgular 0,2 saniyede bitiyorsa kalan 2,2 saniye ya PHP'nin kendi işinde ya da dışarıya yapılan bir HTTP çağrısında harcanıyordur.

Bellek satırında kullanılan miktarın PHP bellek sınırına oranına da bakın. Sınıra yaklaşan bir sayfa bugün açılıyor olabilir, bir içe aktarma ya da büyük bir rapor ekranında ise ölümcül hataya dönüşür. Overview'da nesne önbelleği isabet oranı da görünür. Kalıcı bir nesne önbelleği kullanıyorsanız ve oran sürekli yüzde 0 ya da yüzde 100'de takılı kalıyorsa, Query Monitor'ün yardım sayfası bunu olağan saymıyor. Sürekli yüzde 100'ü Memcached drop-in'indeki düzeltilmiş bir hataya bağlıyor ve drop-in dosyasını güncellemenizi öneriyor. Nesne önbelleğinin hangi sayfalarda fark yarattığını Redis nesne önbelleğinin sayfa önbelleğinden farkını anlattığımız yazıda bulabilirsiniz.

Query Monitor 4 ile gelen Timeline paneli bu ayrımı görsel olarak yapar. Sorguları, HTTP çağrılarını, PHP hatalarını ve zamanlamaları yatay bir zaman ekseninde çizer. Belgenin önerdiği okuma basit: uzun çubuklar süreyi kısaltmak için bakılacak yerlerdir, art arda dizilen ve hiç çakışmayan çubuklar sırayla bekleyen işlemleri gösterir. Bir etikete tıklamak sizi ilgili paneldeki satıra götürür.

Veritabanında suçluyu bulmak

Queries by Component

İşin çoğunu bu panel görür. Sorgular, onları tetikleyen bileşene göre (WordPress çekirdeği, tek tek eklentiler, tema) gruplanır ve toplam süreye göre sıralanır. En çok zaman harcayan bileşen en üstte durur.

Varsayımsal örnek: Bir mağazanın kategori sayfasında panel şöyle bir tablo gösteriyor olsun.

Burada tartışma kısa sürer: filtre eklentisi tek başına 412 sorgu çalıştırıyor ve sorgu süresinin neredeyse tamamı onun. Bir sonraki soru bu sorguların tek tek mi yavaş olduğu, yoksa çok sayıda küçük sorgunun mu biriktiğidir. Cevap iki ayrı panelde.

Slow Queries

Belirli bir süreyi aşan sorgular burada listelenir. Eşik QM_DB_EXPENSIVE sabitiyle belirlenir ve varsayılanı 0,05 saniyedir. Paylaşımlı bir hostingde bu eşik size çok fazla satır gösteriyorsa ve önce en kötüleri görmek istiyorsanız eşiği wp-config.php içinde geçici olarak yükseltebilirsiniz:

define( 'QM_DB_EXPENSIVE', 0.2 );

Her satırda sorgunun metni, onu çağıran fonksiyon ve bileşen görünür. Yavaş sorguların ortak özelliği genelde aynıdır: wp_postmeta ya da wp_options gibi büyük tablolarda indeks kullanamayan bir WHERE koşulu, LIKE '%...%' ile metin araması ya da çok büyük bir sonuç kümesini sıralayan ORDER BY. Sorgunun hangi eklentiye ait olduğunu bilmek, çözümün de yarısıdır: eklentinin ayarlarında o özelliği kısıtlamak, geliştiricisine sorgunun kendisini iletmek ya da alternatif aramak.

Duplicate Queries

Aynı sorgu metniyle birden fazla kez çalışan sorgular burada toplanır, yanında kaç kez çalıştığı ve hangi çağıranlardan geldiği yazar. "Potential troublemakers" sütunu tekrarın büyük olasılıkla kimden kaynaklandığını gösterir. Tipik tablo, bir ürün listesinde her ürün için ayrı ayrı aynı ayarı ya da aynı meta değeri soran bir döngüdür. Elli ürünlük bir sayfada elli kez çalışan bir sorgu tek başına hızlı olsa bile toplamda ciddi bir yük yapar. Kalıcı nesne önbelleği bu tekrarların bir kısmını veritabanına gitmeden karşılar, ama asıl çözüm eklentinin veriyi bir kez çekmesidir.

Queries by Caller

Bileşen düzeyi size hangi eklentiyi gösterir, bu panel ise hangi fonksiyonu. Sorgular onları çağıran fonksiyona göre toplanır ve türlerine göre ayrılır. Çağıranın adına tıkladığınızda ana sorgu listesi o fonksiyona süzülmüş olarak açılır. Geliştiriciye hata bildirirken en işe yarar bilgi budur: "eklentiniz yavaş" yerine fonksiyon adı, sorgu metni ve çalışma sayısı.

Dışarıya giden HTTP çağrıları

Sorgu süresi düşük ama sayfa hâlâ yavaşsa HTTP API Calls paneli çoğu zaman cevabı verir. WordPress'in HTTP API'si üzerinden yapılan her dış istek burada yanıt kodu, sorumlu bileşen ve geçen süreyle listelenir, başarısız istekler ayrıca işaretlenir. Lisans doğrulaması yapan bir tema, her sayfada kur ya da kargo fiyatı soran bir eklenti, sosyal paylaşım sayısını çeken bir bileşen burada görünür.

Bir isteğin 5 saniye sürüp zaman aşımıyla bitmesi, sayfanın her açılışında ziyaretçiye 5 saniye bekletmek demektir. Bunu gördüğünüzde üç şeye bakın: istek her sayfada mı yapılıyor, yanıtı önbelleğe alınıyor mu, hedef servis gerçekten erişilebilir mi? Yönetim ekranlarında yaşanan dış istek gecikmeleri, güncelleme denetimleri ve sunucudan giden bağlantıların engellenmesi gibi konular yönetim paneline özgü yavaşlık nedenleri arasında ayrıca ele alınmayı gerektirir.

PHP hataları, kancalar ve ortam

PHP Errors paneli uyarı, bildirim ve kullanımdan kaldırma (deprecated) mesajlarını sorumlu bileşen ve çağrı yığınıyla gösterir. Bir sayfada yüzlerce uyarı üreten bir eklenti, hata günlüğü açıksa her istekte diske de yazar ve bu küçük ama gerçek bir maliyettir. PHP sürümü yükselttikten sonra bu paneli açmak, hangi eklentinin yeni sürümle sorun yaşadığını hızlıca gösterir. Sürüm geçişinin kendisi için cPanel'de PHP sürümünü güvenle değiştirme adımlarına bakabilirsiniz. Sayfa hiç açılmıyorsa Query Monitor da çalışamaz, o noktada 500 hatası ve beyaz ekranda hata günlüğünden ilerleme yöntemi gerekir.

Hooks & Actions paneli sayfa yüklenirken tetiklenen her aksiyonu ve süzgeci, bunlara bağlı her geri çağırımı öncelik ve bileşen bilgisiyle listeler. Bir yanlış beklentiyi baştan düzeltelim: bu panel geri çağırım başına süre ölçmez. Ona "hangi eklenti nereye bağlanmış?" sorusu için başvurursunuz. Örneğin her istekte çalışan init kancasına ağır bir iş bağlayan eklenti burada görünür. Query Monitor, özel all kancasına bir şey bağlandığında ayrıca uyarır, çünkü bunun performans maliyeti yüksektir.

Environment paneli PHP sürümünü, bellek sınırını, hata raporlama düzeyini ve yüklü PHP eklentilerini, veritabanı sunucusunun türünü ve sürümünü gösterir. Desteğe yazmadan önce bu bilgileri buradan almak işinizi hızlandırır.

AJAX ve REST isteklerini izlemek

Yavaşlık sayfanın kendisinde değil de sonradan gelen isteklerde olabilir: sepetin güncellenmesi, filtreleme, yönetim ekranındaki otomatik kayıt. Bu istekler ayrı sayfa yüklemeleri olduğu için Query Monitor paneli onları göstermez. Eklentinin belgesine göre jQuery ile başlatılan her AJAX yanıtı, hata ayıklama bilgisini HTTP başlıklarında taşır ve PHP hataları tarayıcının geliştirici konsoluna da yazılır.

1. Tarayıcıda geliştirici araçlarını açın, Network (Ağ) sekmesine geçin ve Fetch/XHR süzgecini seçin.
2. Yavaş işlemi tetikleyin (filtreye tıklayın, sepete ürün ekleyin).
3. Uzun süren isteği seçin ve yanıt başlıklarında x-qm- ile başlayan satırları okuyun. Üretim süresi ve bellek kullanımı burada yazar.
4. Console sekmesinde aynı isteğe ait PHP hatası olup olmadığına bakın.

WooCommerce'te sepet ve ödeme adımı bu türden isteklerle doludur. wc-ajax isteklerinin hangisinin yavaş olduğunu bulmak ve sepet ve ödeme sayfasının yavaşlık nedenlerini ayıklamak aynı yöntemle başlar.

REST API istekleri için kimliği doğrulanmış bir istek gerekir. Belgede iki yol var: oturum açıkken wp-admin/admin-ajax.php?action=rest-nonce adresinden bir nonce değeri alıp isteğe _wpnonce parametresiyle eklemek ya da WordPress 5.6 ile gelen uygulama parolalarını kullanmak. Bu durumda yanıta x-qm-overview-time-taken ve x-qm-overview-memory gibi başlıklar eklenir. Daha ayrıntılı veri isterseniz isteğe _envelope parametresini ekleyin. Yanıtın JSON gövdesine sorguları, yinelenenleri, önbellek ve HTTP verisini içeren bir qm alanı gelir:

https://ornek.com.tr/wp-json/wp/v2/posts/?_envelope&_wpnonce=NONCE_DEGERI

Oturum açmadan görmek: kimlik doğrulama çerezi

Bazı sorunlar yalnız ziyaretçide ya da yönetici olmayan rollerde görülür. Üyelik eklentisinin abonelere çalıştırdığı sorgular, yalnız oturum kapalıyken devreye giren bir pop-up eklentisi gibi. Query Monitor'ün Settings panelinde bir kimlik doğrulama çerezi (authentication cookie) tanımlayabilirsiniz. Çerez tarayıcınızda durduğu sürece oturumu kapattığınızda ya da başka bir rolle girdiğinizde de çıktıyı görmeye devam edersiniz.

Burada sık şaşırtan bir durum var. Oturumu kapattığınızda sayfa önbellekten geliyorsa PHP hiç çalışmaz ve Query Monitor'ün çıktısı da görünmez. Bu bir arıza değil, önbelleğin işini yaptığının işaretidir. Sayfanın önbellekten mi üretimden mi geldiğini yanıt başlıklarındaki önbellek durumundan okuyabilirsiniz. Ziyaretçi için yapılan önbelleksiz üretimi ölçmek istiyorsanız yalnız o adresin önbelleğini temizleyip ilk isteği ölçün ya da ölçüm süresince sayfayı geçici olarak önbellek dışında tutun (LSCache'te Do Not Cache URIs listesi gibi).

db.php bağlantısı ne ekler?

Query Monitor etkinleştirildiğinde wp-content klasörüne db.php adında bir sembolik bağlantı (symlink) oluşturmaya çalışır. Bu drop-in dosyası, belgeye göre bütün veritabanı sorguları için sonuç sayısını, tam çağrı yığınını ve hata tespitini etkinleştirir. Eklenti onsuz da çalışır ama bu genişletilmiş bilgiler eksik kalır.

Bağlantı birkaç durumda oluşmaz. wp-content klasörüne PHP yazamıyorsa, aynı yerde başka bir eklentinin db.php dosyası varsa (belge W3 Total Cache, LudicrousDB, HyperDB ve SQLite Database Integration'ı örnek veriyor), PHP'nin symlink fonksiyonu sunucuda kapatılmışsa ya da DISALLOW_FILE_MODS sabiti açıksa. wp-config.php içinde QM_DB_SYMLINK sabitini false yaparak oluşturulmasını kendiniz de engelleyebilirsiniz. Başka bir eklentinin db.php dosyasının üzerine yazmaya kalkmayın. O dosya o eklentinin çalışması için oradadır ve Query Monitor'ün yardım sayfası da bu çakışma için yapılacak bir şey olmadığını açıkça söylüyor. İzinler düzeltildiyse eklentiyi kapatıp yeniden açmak ya da WP-CLI ile wp qm enable komutu bağlantıyı yeniden dener.

Bulguları kaydedin, değişikliği karşılaştırın

Query Monitor geçmiş tutmaz, gösterdiği her şey yalnız o anki istek içindir. Bu yüzden ölçümleri bir yere yazmadan değişiklik yaparsanız elinizde karşılaştıracak bir şey kalmaz. Basit bir bulgu tablosu yeterli:

Tablodaki değerler varsayımsal, biçimi göstermek için konuldu. Yöntemin kuralı şu: bir seferde tek değişiklik yapın, her değişiklikten sonra aynı sayfayı aynı kullanıcı durumunda üç kez ölçün ve ortancayı yazın. Mümkünse denemeleri sitenin hazırlık kopyasında yapın. Eklenti kapatıp açmak canlı sitede ziyaretçiye yansır.

Bir şeyi geri almak gerekirse tablo size neyi geri alacağınızı söyler. Değişikliği geri çevirin, aynı ölçümü tekrarlayın ve sayıların eski hâline döndüğünü görün. Dönmüyorsa arada başka bir şey değişmiştir, örneğin bir eklenti kendiliğinden güncellenmiştir.

İş bitince eklentiyi kapatın

Query Monitor'ün etkisi küçüktür, geliştiricisi de bunu "evet, ama yalnız biraz" diye özetliyor. Yüzlerce sorgu çalıştıran sayfalarda ise her sorgu için tutulan çağrı yığını belleği belirgin biçimde artırır. Teşhis bittiğinde eklentiyi devre dışı bırakın. Bunu yönetim panelinden ya da WP-CLI ile yapın:

wp plugin deactivate query-monitor

Eklentinin kaynak kodundaki devre dışı bırakma adımı, wp-content/db.php kendi dosyasıysa onu siler. Klasör adını FTP'den değiştirerek kapatırsanız bu adım çalışmaz ve bağlantı geride kalır. Kapattıktan sonra wp-content içinde Query Monitor'e ait bir db.php kalmadığını kontrol edin.

Bulgular net ama elinizdeki ortamda yapılabilecek her şey yapıldıysa, sıradaki soru kapasitedir. Önbelleklenemeyen sayfaların ağır olduğu, nesne önbelleği ve güncel PHP gerektiren siteler için WordPress hosting paketlerine bakabilirsiniz. Bulgu tablonuzu destek talebine eklerseniz incelemeye sıfırdan başlamak gerekmez.