Kurulum bitti, panel açıldı, ilk siparişler geliyor. Siteyi kendi tarayıcından açıyorsun, hızlı görünüyor ve konuyu kapatıyorsun. Çoğu satıcının performans ölçümü bu kadardır: kişisel izlenim. Oysa senin tarayıcın en kötü senaryoyu asla göstermez, çünkü sayfa önbelleğe alınmıştır, oturum açıktır, sunucu o an boştur ve sen sayfayı zaten tanıdığın için bekleme süresini hissetmezsin. Ölçtüğün şey hızın değil, alışkanlığındır.
İşin ifşası şurada: bir e-pin satış scripti'nde yavaşlık, hata mesajı üretmez. Kimse "siteniz yavaş" diye yazmaz; sadece sepeti terk eder, kampanya trafiği boşa gider ve sen reklam maliyetini suçlarsın. Yavaşlığın faturası, görünmeyen bir dönüşüm sızıntısı olarak kesilir. Bu yazıda kurulumdan sonra ölçmen gereken metrikleri, ölçümü nasıl yapacağını ve sonuçları hangi sırayla düzelteceğini anlatıyorum; tahmin yerine sayı ile çalışacaksın.
Ortalamaya bakıyorsun, oysa sorun uçlarda saklı
Performans raporlarının en yanıltıcı satırı ortalamadır. Yüz isteğin doksan beşi 150 milisaniyede, beşi 6 saniyede dönüyorsa ortalama yaklaşık 440 milisaniye çıkar ve tablo iyi görünür. Ama o beş yavaş istek rastgele dağılmaz; genellikle en pahalı sayfalarda toplanır: kategori filtreleme, sepet güncelleme ve ödeme dönüşü. Yani yavaşlık, tam olarak paranın döndüğü yerde yoğunlaşır.
Bu yüzden ölçüme p50 (medyan), p95 ve p99 üçlüsüyle başla. Medyan "normal gün" hissini verir, p95 gerçek müşteri deneyimini gösterir, p99 ise altyapının kırılma noktasını işaret eder. İkinci ayrım da eşit derecede önemli: sunucu tarafı ölçümü (TTFB, sorgu süresi, PHP işlem süresi) ile tarayıcı tarafı ölçümü (LCP, INP, CLS) ayrı dünyalardır. Sunucu 80 milisaniyede yanıt verip sayfa 5 saniyede görünür hale geliyorsa suçlu betikler ve görsellerdir; TTFB 1,8 saniyeyse suçlu veritabanı veya bir dış çağrıdır.
| Metrik | Nerede ölçülür | Hedef | Aşılırsa ilk şüpheli |
|---|---|---|---|
| TTFB (ilk bayt) | Sunucu / curl | < 200 ms | Yavaş sorgu, dış API, önbellek yok |
| LCP | Tarayıcı / alan verisi | < 2,5 sn | Optimize edilmemiş görsel, blokajlı CSS |
| INP | Tarayıcı | < 200 ms | Ağır JS, gereksiz üçüncü parti |
| Sorgu sayısı / sayfa | Uygulama profili | < 40 | N+1 döngüsü, eksik ilişki yükleme |
| En yavaş sorgu | slow query log | < 100 ms | Eksik indeks, tam tablo taraması |
| Opcache isabet oranı | PHP durumu | > %98 | Küçük bellek, sık geçersiz kılma |
| Tedarikçi API yanıtı | Teslimat logu | < 1,5 sn | Eş zamanlı çağrı, zaman aşımı yok |
| Hata oranı (5xx) | Sunucu logu | < %0,1 | Bellek sınırı, süreç tükenmesi |
Ölçüme nereden başlanır? Üç komut, on dakika
Karmaşık araçlara gerek yok; ilk resmi üç adımda çekebilirsin. Birincisi ham TTFB ölçümü: curl -o /dev/null -s -w "dns:%{time_namelookup} baglanti:%{time_connect} ilkbayt:%{time_starttransfer} toplam:%{time_total}\n" https://alanadin.com/urun/ornek. Bunu önbellek etkisini görmek için art arda beş kez çalıştır; ilk istek yavaş, sonrakiler hızlıysa önbellek çalışıyor demektir. Hepsi yavaşsa sorun uygulama katmanındadır.
İkincisi yük altında davranış: küçük bir eşzamanlılık testi yap, örneğin 10 paralel bağlantıyla 200 istek. Amaç sunucuyu kırmak değil, eğrinin nerede büküldüğünü görmektir. Yanıt süresi eşzamanlılıkla doğrusal artıyorsa PHP süreç sayısı veya veritabanı bağlantı havuzu darboğazdır. Üçüncüsü gerçek kullanıcı verisi: panele hafif bir zamanlama kaydı ekle ve her isteğin süresini, sorgu sayısını, bellek kullanımını yaz. Sentetik test sana laboratuvarı, bu kayıt sahayı gösterir. İyi tasarlanmış bir e-pin yazılımı bu ölçümü kendi geliştirici modunda hazır sunar; kapsamı özellikler bölümünde görebilirsin.
Kurulum sonrası yavaşlığın kaynak dağılımı
- Veritabanı sorguları 45%
- Tedarikçi ve dış API çağrıları 25%
- PHP, opcache ve uygulama katmanı 20%
- Ağ ve statik varlıklar 10%
Yavaş sorgu avı: en büyük kazanç burada
Deneyimin söylediği şey net: kurulum sonrası yavaşlığın yarısına yakını veritabanından gelir ve genellikle iki desende toplanır. Birincisi eksik indeks. Sipariş listesini müşteri e-postasına göre filtreliyorsan ve o kolonda indeks yoksa, tablo on bin satıra ulaştığında sorgu her seferinde tüm tabloyu tarar. İkincisi N+1 döngüsü: kategori sayfası yirmi ürün listeler, sonra her ürün için ayrı bir stok sorgusu atar. Kırk bir sorgu yerine iki sorgu yeterliyken kırk bir sorgu atılır.
Avı şöyle yap: MySQL tarafında slow_query_log'u aç ve long_query_time'ı 0,2 saniyeye indir. Bir gün topla, sonra en sık tekrarlayanı değil, toplam süresi en yüksek olanı seç; günde bin kez koşan 120 milisaniyelik bir sorgu, günde iki kez koşan 3 saniyelik rapordan daha pahalıdır. Adayı EXPLAIN ile incele; type: ALL ve büyük rows değeri gördüğün yerde indeks eksiktir. İndeks eklemeyi de ölçerek yap: her eklenen indeks yazma işlemini bir miktar yavaşlatır, bu yüzden "her kolona indeks" yaklaşımı sipariş oluşturmayı yavaşlatır.
Ürün sayfası açılırken canlı stok için tedarikçiye sorulan her çağrı, sayfanın hızını senin kontrolünde olmayan bir sunucuya bağlar. Tedarikçi 4 saniyede yanıt verdiği gün sayfan 4 saniyede açılır. Doğru desen, stoku cron ile arka planda senkronize edip sayfada yerel veriyi göstermek; ayrıca her dış çağrıya kısa bir zaman aşımı ve yedek davranış tanımlamaktır.
Uygulama ve sunucu katmanı: ucuz ama atlanan ayarlar
Veritabanını düzelttikten sonra sıra PHP tarafındadır ve buradaki kazançlar genellikle tek bir yapılandırma satırı kadar ucuzdur. İlk kontrol opcache'dir. Kapalıysa her istekte tüm PHP dosyaları yeniden derlenir ve TTFB iki-üç kat şişer. Açıkken bile isabet oranı düşükse bellek küçüktür veya dosya sayısı sınırı aşılmıştır; memory_consumption ve max_accelerated_files değerlerini kurulum büyüklüğüne göre yükselt.
İkinci kontrol önbellek katmanlarıdır. Kategori listeleri, kur bilgisi ve menüler her istekte yeniden hesaplanmak zorunda değildir; kısa süreli bir nesne önbelleği bu yükü büyük ölçüde siler. Üçüncü kontrol statik varlıklardır: görselleri modern formata çevirmek, uzun süreli tarayıcı önbelleği başlıkları vermek ve gereksiz üçüncü parti betikleri kaldırmak LCP üzerinde en hızlı etkiyi yaratır. Unutma, canlı destek, analitik ve piksel betiklerinin toplamı sık sık scriptin kendi JavaScript'inden daha ağırdır. Bir dijital ürün satış scripti ne kadar iyi yazılmış olsa da, önüne yığdığın altı üçüncü parti etiketi telafi edemez.
Ölçümü rapora, raporu karara çevir
Son adım, ölçümü alışkanlığa dönüştürmektir. Tek seferlik test bir fotoğraftır; sana asıl gereken filmdir. Haftalık basit bir tablo tut: tarih, p50, p95, en yavaş üç sayfa, en pahalı üç sorgu, 5xx oranı, ortalama teslimat süresi. Bir güncelleme veya yeni bir eklenti sonrası p95 yüzde otuz bozulduysa sebebini o hafta bulursun; üç ay sonra bulmaya kalkarsan arada yirmi değişiklik olur ve iz kaybolur.
İyileştirme sırasını da ölçüme göre kur, moda göre değil. Doğru sıra genellikle şudur: önce yavaş sorguları ve N+1'i temizle, sonra dış çağrıları istek akışından çıkar, ardından opcache ve nesne önbelleğini ayarla, en sonunda statik varlıkları ve üçüncü parti betikleri sıkılaştır. En yaygın hata bu sırayı tersten yürütmektir: insanlar görsel sıkıştırmayla başlar, oysa darboğaz 1,4 saniyelik bir sipariş sorgusudur ve o sorgu durdukça hiçbir görsel optimizasyonu fark yaratmaz.
| Kontrol | Araç / yöntem | Eşik | Sıklık |
|---|---|---|---|
| Ana sayfa ve ürün TTFB | curl zamanlama çıktısı | 200 ms altı | Haftalık |
| Ödeme akışı p95 | Uygulama zamanlama kaydı | 800 ms altı | Haftalık |
| Yavaş sorgu listesi | slow query log + EXPLAIN | Yeni giriş yok | Haftalık |
| Sayfa başına sorgu sayısı | Geliştirici profili | 40 altı | Her sürümde |
| Opcache isabet oranı | PHP durum sayfası | %98 üstü | Aylık |
| Tedarikçi çağrı gecikmesi | Teslimat log analizi | 1,5 sn altı | Haftalık |
| Üçüncü parti betik ağırlığı | Tarayıcı ağ paneli | 150 KB altı | Aylık |
| Yük altında hata oranı | Eşzamanlılık testi | %0,1 altı | Kampanya öncesi |
Ölçülebilir bir altyapıyla başla, tahminle uğraşma
Pinova; sorgu profili, teslimat logları ve arka plan senkronizasyonuyla performansı görünür kılar. Sürümleri ve fiyatlandırmayı karşılaştırmak için panele göz at.
Kurulumdan hemen sonra performans testi yapmak anlamlı mı?
Evet, çünkü o an temiz bir taban çizgisi elde edersin. Veri büyüdükçe ve eklenti eklendikçe karşılaştıracağın referans noktası bu ilk ölçümdür. Taban çizgisi olmadan "yavaşladı mı?" sorusuna sayı ile cevap veremezsin.
Sunucuyu yükseltmek yavaşlığı çözer mi?
Genellikle geçici olarak maskeler. Darboğaz eksik indeks veya N+1 döngüsüyse daha güçlü sunucu aynı hatayı biraz daha hızlı yapar, veri büyüyünce sorun geri döner. Önce ölç ve kök nedeni kaldır, donanımı en son düşün.
Hangi metrik dönüşümle en çok ilişkili?
Ödeme ve sepet adımlarının p95 süresi ile ürün sayfası LCP değeri. Bu iki nokta doğrudan satın alma kararının önünde durur; ana sayfa hızının dönüşüme etkisi çoğu kurulumda daha sınırlıdır.
Ölçümü otomatikleştirmenin en basit yolu nedir?
Günlük bir zamanlanmış görevle kritik üç sayfaya curl zamanlama ölçümü yap, sonucu tabloya yaz ve eşik aşıldığında bildirim üret. Basit ama kalıcı bir eğri elde edersin; pahalı araçlara başlamak için gerekçen de olur.
Performans, e-pin satışında sessiz bir dönüşüm kaldıracıdır: kimse övmez, ama bozulduğunda faturayı reklam bütçenden keser. Kurulumdan sonra taban çizgini al, p95'i takip et, yavaş sorguları avla ve dış çağrıları istek akışından çıkar. Bu yaklaşımı destekleyen bir yapıyı kendi elinle test etmek istersen canlı demo üzerinde ürün, sepet ve ödeme akışını sırayla gezerek yanıt sürelerini kendi ölçümlerinle karşılaştırabilirsin.