Epin Scripti Performans Darboğazını Bulmak: Panelin Yavaşlamasının Gerçek Sebebi Sunucun Değil, İşte Kimsenin Bakmadığı O Dört Satır

Panelin yavaşladığında ilk refleks hep aynıdır: sunucuyu yükselt. Çoğu kişi bunun bir çözüm olduğunu sanır ve gerçekten de ilk hafta rahatlar. Sonra yavaşlık geri gelir, üstelik bu kez faturası daha yüksektir. Çünkü donanım eklemek darboğazı çözmez, sadece erteler. Darboğaz dediğimiz şey kapasite eksikliği değil, akışın en yavaş halkasıdır ve o halkayı bulmadan yapılan her yatırım para yakmaktır.

İyi haber şu: e-pin panellerinde darboğazın nerede olduğu neredeyse hep aynı dört yerden birindedir ve hepsi ölçülebilir. Bu yazıda bir e-pin scripti üzerinde çalışan sistemin yavaşlık kaynağını sistematik biçimde nasıl bulacağını anlatıyoruz. Tahminle değil, sayıyla. Sonunda elinde hangi halkaya dokunacağını söyleyen net bir sıralama olacak.

Ölçmediğin bir yavaşlığı neden asla düzeltemezsin?

Darboğaz avı, hissi ölçüme çevirmekle başlar. "Panel yavaş" cümlesi teknik olarak hiçbir şey söylemez. Onun yerine üç sayıyı ayır: tarayıcının ilk baytı bekleme süresi, sunucunun istek işleme süresi ve veritabanının toplam sorgu süresi. Bu üçü arasındaki fark sana suçluyu gösterir. İlk bayt uzun ama sunucu işleme süresi kısaysa sorun ağ veya önbellek katmanındadır. Sunucu işleme uzun ama sorgu süresi kısaysa sorun kod tarafındadır. Sorgu süresi tüm işleme süresinin yarısından fazlaysa suçlu bellidir. Ölçümü tek bir sayfada değil en az beş kritik akışta yap: ürün listesi, sepet, ödeme dönüşü, sipariş detayı ve yönetici raporu. Bir dijital ürün satış scripti bu beş akışta çok farklı davranabilir.

Sorgu sayısı neden süreden daha önemli bir işaret?

Tek bir sorgunun iki yüz milisaniye sürmesi kötüdür, ama iki yüz sorgunun her birinin iki milisaniye sürmesi çok daha kötüdür. İkinci durum, klasik N+1 desenidir: elli siparişi listelerken her sipariş için ayrıca ürün, kullanıcı ve fatura bilgisi çekilir. Sayfa görünürde hızlıdır, çünkü her sorgu ucuzdur; ama yük arttığında veritabanı bağlantı havuzu dolar ve sistem bir anda duvara çarpar. Bu yüzden darboğaz avında ilk bakacağın metrik sayfa başına sorgu sayısıdır. Sağlıklı bir liste sayfası yirmi sorgunun altında kalmalıdır. Yüzü geçiyorsa optimizasyona bile gerek yok; ilişkili veriyi tek seferde çekecek biçimde yeniden yazmak zorundasın. İyi yazılmış bir e-pin satış yazılımı bu deseni baştan engeller.

Tedarikçi beklemesi kendi kodunmuş gibi neden görünür?

Sipariş onayı yavaşsa çoğu kişi kodunu suçlar, oysa süre büyük olasılıkla dışarıda geçiyordur. Tedarikçi API'sine yapılan çağrı iki saniye sürdüğünde, o iki saniye senin sunucu istatistiğinde "işleme süresi" olarak görünür ve yanlış yere bakarsın. Çözüm, akışın her adımına zaman damgası basmaktır: sipariş kaydı, ödeme doğrulama, tedarikçi çağrısı, kod yazımı, bildirim. Bu beş damgayı yan yana koyduğunda sürenin nerede eridiği bir bakışta belli olur. Ölçüm sonrası müdahale nettir: dış çağrıyı kullanıcının beklediği akıştan çıkar, stok havuzundan teslim et, senkronizasyonu arka plana al. Bu düzenleme tek başına sipariş onay süresini çoğu kurulumda üçte bire indirir. Hangi adımların hazır olarak ayrıştırıldığını özellikler listesinde görebilirsin.

Şablon ve görsel yükü gerçekten önemsiz mi?

Sunucu tarafı yüz milisaniyede cevap veriyor ama kullanıcı sayfayı üç saniyede görüyorsa, darboğaz artık tarayıcıdadır. E-pin panellerinde bunun en yaygın sebebi, sıkıştırılmamış ürün görselleri ve gereksiz betik yüklemeleridir. Elli ürünlük bir listede her görsel iki yüz kilobayt ise, ziyaretçi on megabayt indiriyor demektir. Görselleri modern formata çevirip boyut sınırı koymak sayfa süresini yarıya indirir. İkinci kalem gereksiz betiklerdir: sipariş sayfasında çalışması gerekmeyen üçüncü taraf kodları, kullanıcının kod görme süresini uzatır. Kural basit: ödeme ve teslim akışında yalnızca o akış için zorunlu olan kaynak yüklenir. Geri kalanı ertelenir ya da kaldırılır.

İndeks eklemek her zaman doğru cevap mı?

İndeks, okuma sorgularını uçurur ama yazma işlemlerini yavaşlatır ve disk alanı tüketir. E-pin panelinde sipariş tablosu hem çok okunur hem çok yazılır; bu yüzden her sütuna indeks atmak sipariş oluşturma süresini uzatır. Doğru yaklaşım hedeflidir: yavaş sorgu kaydını aç, iki hafta veri topla, en çok tekrar eden ve en uzun süren üç sorguyu al, yalnızca onların filtre ve sıralama sütunlarına bileşik indeks ekle. Ardından ölçümü yeniden yap. Genelde üç dört indeks, yavaşlığın büyük kısmını bitirir. Bunun ötesinde indeks eklemeye devam etmek fayda eğrisinin düz kısmına girmektir; oradan sonra kazanç yerine yazma maliyeti artar. Ayrıca eski verileri arşivlemeyi unutma: üç yıllık sipariş kaydını aynı tabloda tutmak her sorguyu gereksiz ağırlaştırır.

Yazılımın kendi kalitesi bu denklemin neresinde duruyor?

Bütün bu iyileştirmeler, temeli sağlam bir sistemde kalıcı sonuç verir. Kötü kurgulanmış bir epin yazılım kurulumunda ise her optimizasyon geçici olur; bir sonraki güncellemede sorgu sayısı yine patlar. Bu yüzden darboğaz avının son adımı, tekrar eden sorunların kaynağını sormaktır. Sipariş akışı her seferinde aynı yerde tıkanıyorsa, sorun senin ayarında değil mimaride olabilir. Pinova burada e-pin satmaz; e-pin satanın altyapısını, sorgu disiplini ve ayrıştırılmış arka plan akışıyla kurar. Böylece performans çalışmanı her ay baştan yapmak zorunda kalmazsın. Hacmine uygun paketi fiyat bölümünde karşılaştırabilirsin.

Darboğazı bulmak, panelini hızlandırmaktan daha değerli bir beceridir; çünkü bir kez öğrendiğinde her yeni sorunu aynı yöntemle çözersin. Hazır bir sistemin bu ölçüm ve ayrıştırma disiplinini nasıl kurduğunu görmek için canlı demo üzerinden sipariş akışını uçtan uca dene.