Site yavaşladığında herkesin aklına gelen ilk çözüm aynıdır: daha güçlü sunucu. Paket yükseltilir, çekirdek sayısı artırılır, bellek iki katına çıkarılır. İlk gün bir rahatlama olur, ikinci hafta aynı yavaşlık geri döner. Çünkü yavaşlığın kaynağı çoğu zaman kapasite değildir; aynı işin gereksiz biçimde onlarca kez yapılmasıdır. Donanım eklemek, verimsizliği biraz daha uzun süre gizlemekten başka bir şey yapmaz.
Bir epin satış panelinde yavaşlığın anatomisi de oldukça öngörülebilir. Ürün listesi, kur dönüşümü, kategori ağacı, stok sayımı, oturum yönetimi ve kayıt tabloları; yedi sekiz noktadan biri bozulunca sayfa açılış süresi katlanır. Bu yazıda bu noktaları tek tek gezeceğiz, her biri için nasıl ölçüm yapacağını göstereceğiz ve paranı sunucuya değil doğru yere harcamanın yolunu anlatacağız.
Ölçmediğin bir yavaşlığı hiç çözemezsin: nereye bakacaksın?
Yavaşlık tartışmalarının çoğu tahminle yürür. "Sanırım sunucu zayıf", "bence görseller büyük". Bu tahminlerle çalışmak, karanlıkta tamir yapmaya benzer. İlk yapman gereken, toplam açılış süresini üç parçaya bölmektir: sunucunun ilk baytı üretme süresi, dosyaların indirilme süresi, tarayıcının ekrana çizme süresi.
Bu üçlüyü ayırdığın anda iş kolaylaşır. İlk bayt süresi yüksekse sorun tamamen sunucu tarafındadır; görselleri sıkıştırmakla zaman kaybetme. İlk bayt hızlıysa ama sayfa geç görünüyorsa sorun ön yüzdedir; veri tabanına dokunmanın anlamı yok. Ayrıca ölçümü her zaman aynı koşullarda yap: aynı sayfa, aynı saat dilimi, önbellek boş ve dolu hallerde ayrı ayrı. Ölçüm disiplini olmayan bir ekip, aynı sorunu her ay yeniden keşfeder.
Ürün listesi neden yüz kat fazla sorgu atıyor?
Bir e-pin satış scriptinde en sık görülen darboğaç, liste sayfalarındaki katmerli sorgu davranışıdır. Ürünler tek sorguyla çekilir, sonra her ürün için kategori adı, stok sayısı, kur bilgisi ve indirim kontrolü ayrı ayrı sorgulanır. Sayfada 40 ürün varsa toplam sorgu sayısı hızla üç yüzü aşar. Her biri milisaniyeler sürer ama toplamı saniyelere ulaşır.
Çözümü basittir ve donanım gerektirmez: ilişkili verileri toplu çekmek. Kategorileri tek sorguda alıp bellekte eşleştir, stok sayımlarını gruplanmış tek sorgu haline getir, kur bilgisini döngüye hiç sokma. Bir de listeleme sorgusunda gerçekten ihtiyacın olmayan alanları çekmeyi bırak: uzun açıklama metinleri, teknik detay alanları, geçmiş kayıtları. Bu iki müdahale çoğu dijital ürün satış yazılımında açılış süresini yarıdan fazla düşürür ve tek kuruş altyapı masrafı çıkarmaz.
İndeks eksikliği: sessiz ama en pahalı hata
Veri tabanı büyüdükçe indeks eksikliği kendini gösterir. Bin kayıtta hiç fark edilmez, elli bin kayıtta sayfa kilitlenir. Kritik alanlar bellidir: ürün kimliği, sipariş numarası, kullanıcı kimliği, durum alanı, tarih alanı ve kod havuzundaki arama alanları. Bu kolonlarda indeks yoksa her sorgu tüm tabloyu baştan sona tarar.
Burada dikkat edilecek nokta, indeksin bedava olmadığıdır. Her indeks yazma işlemini biraz yavaşlatır ve disk alanı tüketir. Bu yüzden "her kolona indeks" yaklaşımı da hatalıdır. Doğru yöntem, yavaş sorgu kaydını açıp gerçekten hangi sorguların uzun sürdüğünü görmek, sonra sadece o sorguların ihtiyaç duyduğu bileşik indeksleri eklemektir. Sıralama ve filtreleme birlikte kullanılan yerlerde tek kolonlu indeksler yetersiz kalır; kolon sırasını sorgunun kullanım biçimine göre belirlemek gerekir.
| Darboğaz | Tipik belirti | Ölçüm yolu | Beklenen kazanç |
|---|---|---|---|
| Döngü içinde sorgu | Liste yavaş, detay hızlı | Sorgu sayacı aç | %35-60 |
| İndeks eksikliği | Veri büyüdükçe kötüleşiyor | Yavaş sorgu kaydı | %20-50 |
| Bayt kodu önbelleği kapalı | Her istek eşit yavaş | Sunucu modül bilgisi | %15-30 |
| Oturum dosyası kilidi | Eşzamanlı istekler sıraya giriyor | Paralel istek testi | %10-40 |
| Şişmiş kayıt tabloları | Panel yönetimi çok yavaş | Tablo boyut raporu | %10-25 |
| Optimize edilmemiş görsel | İlk bayt hızlı, çizim geç | Ağ sekmesi boyutları | %15-35 |
| Senkron dış servis çağrısı | Rastgele uzun beklemeler | Zaman aşımı kayıtları | %20-45 |
Panelini kendi kayıtların mı boğuyor?
Az konuşulan ama sık rastlanan bir durum var: sistemin kendi tuttuğu kayıtların panelini yavaşlatması. İşlem geçmişi, oturum kayıtları, hata günlükleri, bildirim tabloları ve teslim denemeleri zamanla milyonlarca satıra ulaşır. Yönetim ekranındaki masum bir sayaç, bu dev tabloda sayım yaptığı için her sayfa yüklemesinde saniyeler harcar.
Çözüm kayıt tutmayı bırakmak değil; kayıtları katmanlamaktır. Sıcak veri son doksan günü kapsar ve hızlı erişilir. Daha eskisi arşiv tablosuna taşınır, gerektiğinde ayrı bir ekrandan sorgulanır. Yönetim ekranlarındaki sayaçlar ise anlık sayım yerine günlük hesaplanmış özet tablolardan beslenir. Bir e-pin satış yazılımında bu düzenleme uygulandığında yönetim panelinin hızlanması genelde en çok şaşırtan sonuçtur, çünkü çoğu kişi yavaşlığın müşteri tarafından geldiğini varsayar.
Açılış süresinin tipik dağılımı (optimize edilmemiş panel)
- Veri tabanı sorguları 38%
- Sunucu tarafı işleme 28%
- Varlık indirme (görsel/betik) 20%
- Dış servis bekleme 14%
Dış servisler seni bekletiyorsa sayfan onların kaderine bağlı
Yavaşlığın en sinsi kaynağı dış bağımlılıklardır. Kur servisi, tedarikçi sorgusu, ödeme sağlayıcısı, kısa mesaj servisi, sohbet aracı. Bunların biri yavaşladığında senin sayfan da yavaşlar, çünkü istek tamamlanmasını bekler. Üstelik bu yavaşlık rastgele görünür; günün belli saatlerinde ortaya çıkıp kaybolur, bu yüzden teşhis edilmesi zordur.
Kural nettir: sayfanın açılması hiçbir dış servise bağlı olmamalıdır. Kur bilgisi arka planda güncellenip veri tabanına yazılır, sayfa oradan okur. Tedarikçi doğrulaması yalnızca satış anında ve kısa bir zaman aşımıyla yapılır. Bildirimler kuyruğa alınır, arka planda gönderilir. Her dış çağrıya makul bir zaman aşımı ve başarısızlık durumunda çalışacak bir yedek davranış tanımlanır. Bu düzenleme yapıldığında bir servis çöktüğünde sitenin tamamı değil, yalnızca o özellik devre dışı kalır.
Hangi sırayla müdahale edersen en hızlı sonuç alırsın?
Optimizasyonun bir sırası vardır ve bu sıra ihlal edildiğinde çok emek harcayıp az sonuç alırsın. İlk adım ölçümdür: sorgu sayacı ve yavaş sorgu kaydı aç. İkinci adım en pahalı sorguyu düzeltmektir; genelde tek bir liste sayfası toplam yükün yarısını üretir. Üçüncü adım bayt kodu önbelleği ve nesne önbelleği gibi altyapı ayarlarıdır. Dördüncü adım varlık tarafıdır: görsel formatı, sıkıştırma, gereksiz betikler.
Bu sıra korunduğunda çoğu panel, sunucu değiştirmeden hedeflenen hıza ulaşır. Yükseltme kararı ancak yazılım tarafındaki bu dört adım tamamlandıktan sonra anlamlıdır; o noktada gerçekten kapasite sınırına gelmişsen donanım eklemek işe yarar. Pinova tarafında bu mantık baştan kuruludur: liste sorguları toplu çalışır, sayaçlar özet tablodan beslenir, dış çağrılar arka plana alınır. Teknik özelliklere göz atarak hangi başlıkların hazır geldiğini görebilirsin.
Aynı sayfayı bir kez giriş yapmış, bir kez çıkış yapmış halde aç. Giriş yapınca belirgin biçimde yavaşlıyorsa sorun oturum kilidi veya kişiye özel sorgulardadır; iki durumda da eşit yavaşsa darboğaz ortak sorgu katmanındadır. Bu ayrım aramanı yarıya indirir.
| Kontrol maddesi | Sıklık | Hedef değer | Öncelik |
|---|---|---|---|
| Sayfa başına sorgu sayısı | Her sürümde | 40 altı | Kritik |
| İlk bayt süresi | Haftalık | 300 ms altı | Kritik |
| Bayt kodu önbelleği aktif mi | Aylık | Açık ve isabetli | Yüksek |
| Yavaş sorgu kaydı inceleniyor mu | Haftalık | 1 sn üstü sorgu yok | Yüksek |
| Kayıt tabloları arşivlendi mi | Aylık | Sıcak veri 90 gün | Orta |
| Dış çağrılarda zaman aşımı var mı | Kurulumda | 3 sn ve yedek davranış | Kritik |
| Görseller modern formatta mı | Aylık | Sayfa toplamı 1 MB altı | Orta |
Sunucu paketini büyütmeden önce doğru soruyu sor
Toplu sorgu, özet tablolar, arka plana alınmış dış çağrılar ve doğru indekslenmiş bir veri modeli; hızın gerçek kaynağı budur. Yazılımın bunları hazır sunması, her yıl artan altyapı faturasından çok daha değerlidir. Paketleri incele.
Sunucumu yükselttim ama hız değişmedi, neden?
Darboğaz işlemci veya bellek değilse yükseltmenin etkisi sınırlı kalır. Döngü içinde çalışan sorgular, indeks eksikliği veya dış servis beklemeleri daha güçlü donanımda da aynı süreyi harcar. Önce sorgu sayısını ve ilk bayt süresini ölçmek gerekir.
Kaç sorgu normal kabul edilir?
Bir liste sayfası için 40 altı makul, 20 altı iyi sayılır. Üç yüzü aşan bir sayfa neredeyse kesin olarak döngü içinde sorgu atıyordur. Bu sayıyı ölçmek için geliştirme ortamında basit bir sorgu sayacı açmak yeterlidir.
Kayıtları silmek hız için doğru bir çözüm mü?
Silmek yerine arşivlemek daha güvenlidir; çünkü işlem geçmişi hem muhasebe hem anlaşmazlık çözümü için gereklidir. Eski kayıtları ayrı tabloya taşımak, aynı hız kazancını veri kaybı riski olmadan sağlar.
İçerik dağıtım ağı kullanmak yavaşlığı çözer mi?
Yalnızca statik dosya indirme süresini kısaltır. Sorun sunucunun sayfa üretme süresindeyse etkisi çok düşük olur. Önce ilk bayt süresini ölçüp darboğazın üretim tarafında mı indirme tarafında mı olduğuna karar vermelisin.
Hız, dijital ürün satışında bir konfor değil doğrudan bir dönüşüm parametresidir; açılış süresindeki her yarım saniye sepete ekleme oranını hissedilir biçimde aşağı çeker. İyi haber şu ki bu kazancın büyük kısmı para harcayarak değil, doğru kurulmuş bir veri modeli ve disiplinli ölçümle elde edilir. Kendi panelinle karşılaştırmak istersen canlı demo üzerinde liste sayfalarının açılış hızını dene, ardından kurulum adımına geçmeye karar verebilirsin.