“Mağaza yavaş” ifadesi, yararlı bir müşteri geri bildirimi olmakla birlikte, yetersiz bir teşhistir. İlk kez ziyaret eden bir kullanıcı için yavaş yüklenen bir kategori sayfası, ödeme yöntemi seçildikten sonra takılan bir ödeme işlemi talebinden farklı bir sorundur.
İlk adımım, şikayeti tekrarlanabilir bir istek haline getirmektir: bir URL, müşterinin durumu, cihaz, yaklaşık zaman ve gerçekleştirilen eylem. Bunlar olmadan, altyapı değişiklikleri genellikle çalıştırılması en kolay olan performans testini iyileştirme eğilimindedir.
Herhangi bir ayar yapmadan önce gecikmeyi belirleyin
Üç farklı unsuru ayrı ayrı ele alıyorum: sunucunun yanıt vermeye başlaması ne kadar sürer, tarayıcının sayfayı oluşturması ne kadar sürer ve bir kullanıcı eyleminin tamamlanması ne kadar sürer. Tarayıcı gereksiz komut dosyalarını çalıştırmakla meşgulse, hızlı bir HTML yanıtı bile kötü bir kullanıcı deneyimine yol açabilir.
Ayrıca, anonim ve kimlik doğrulaması yapılmış trafiği de karşılaştırıyorum. Sağlıklı bir genel sayfa önbelleği, bir oturum yanıtı her değiştirdiğinde ortaya çıkan, kaynak tüketen bir uygulama yolunu gizleyebilir. Önceden yüklenmiş bir sayfanın tekrar tekrar yenilenmesi, müşteri yolculuğunu yansıtmaz.
Kullanışlı bir araştırma kaydı, istek zamanını, önbellek durumunu, yanıt boyutunu, uygulama izlemesini ve aynı zaman aralığına ait ilgili altyapı metriklerini içerir. Bu gözlemleri birbiriyle eşleştirmek, birbiriyle ilgisiz ortalamalardan oluşan geniş bir gösterge paneli derlemekten daha önemlidir.
İsteği yığın boyunca takip edin
Önbelleğe alınmamış bir istek söz konusu olduğunda, sorunu içe doğru inceliyorum. Web sunucusu, kullanılabilir bir PHP işleyicisini mi bekliyor? PHP, veritabanında zaman mı harcıyor? Bir modül, uzak bir hizmete senkron bir istek mi gönderiyor? İstek, katalog işlemleriyle rekabet halinde mi?
| Gözlem | Sonraki soru |
|---|---|
| İthalat sırasında gecikmeler artıyor | Dizin oluşturma veya veritabanına yazma işlemleri, müşteri istekleriyle çakışıyor mu? |
| Yalnızca oturum açılmış sayfalarda yavaşlık yaşanıyor | Hangi önbelleğe alınmamış bloklar veya müşteriye özgü işlemler baskın çıkıyor? |
| Ödeme işlemi ara sıra duruyor | Nakliye, vergi veya ödeme bağımlılığından biri, geçerli bir zaman aşımı süresi olmadan beklemede mi? |
| Sunucu yanıtı hızlı, etkileşim yavaş | Tarayıcının ana iş parçacığını ne meşgul ediyor? |
Bellek ve sonraki aşamadaki kapasiteyi tam olarak anlayana kadar işçi sayısını artırmaktan kaçınıyorum. Eşzamanlı olarak yürütülen daha fazla PHP işi, uygulama katmanındaki bir kuyruğu veritabanında daha büyük bir kuyruğa dönüştürebilir. Eşzamanlılık değişiklikleri, ölçümlerle gerekçelendirilmelidir.
Eklentiler tarafından eklenen değişiklikleri inceleyin
Magento’nun uzantı modeli, tek tek makul olan birçok modülün tek bir isteğe ek yük getirmesini kolaylaştırır. Bir ürün listesi, ek koleksiyon yüklemelerini, uzaktan kontrolleri veya tekrarlanan yapılandırma okumalarını tetikleyebilir. Müşterinin deneyimlediği şey, tüm bunların toplam maliyetidir.
Kontrollü bir ortamda, şüpheli davranış devre dışı bırakılmış haldeyken izleri karşılaştırıyorum. Amaç, gecikmeden sorumlu olan işlemi tespit etmektir; her üçüncü taraf modülünü sorunlu olarak etiketlemek değil. Bir özellik gerekliyse, bu özelliğin işleyişini kritik istek yolunun dışına taşımak doğru çözüm olabilir.
Önbellekleme, yalnızca önbellek anahtarı ve geçersiz kılma davranışı verilerle eşleştiğinde işe yarar. Müşteriye özgü bilgiler, sırf zaman çizelgesini iyileştirmek amacıyla paylaşılan içerik haline getirilmemelidir. Adobe’nin önbellekleme belgeleri, platformun önbellek katmanlarını değiştirmeden önce bunları anlamak açısından yararlıdır.
Yavaş vakalar da dahil olmak üzere bir süreçle karşılaştırarak doğrulayın
Doğrulama sürecim, bir kategori sayfası, varyantları olan bir ürün, sepete ekleme, ödeme sayfasına geçiş ve ilgili entegrasyon sınırını içermektedir. Tek bir başarılı örnek sunmak yerine, daha yavaş yanıtlar da dahil olmak üzere isteklerin dağılımını karşılaştırıyorum.
Bu değişikliğin operasyonel bir kontrolü de gereklidir. Veritabanı yükü arttı mı? Zamanlanmış işler gecikti mi? Sayfa hızlanırken hata oranı arttı mı? Yerel bir iyileştirme, sorunu daha az göze çarpan bir yere kaydırabilir.
İlk gecikmeyi açıklayabildiğimde, etkilenen yolculuğun benzer koşullar altında nasıl iyileştiğini gösterebildiğimde ve yoğun dönemlerde bu değişikliğin nasıl işlediğini tanımlayabildiğimde, araştırmayı tamamlanmış sayarım. Bu açıklama, bir dizi yeni sunucu yükseltmesinden daha faydalıdır.
25 Eylül 2026 tarihinde güncellenmiştir.