Bir yedek parça toptancısı düşünün. Sipariş ve cari takibi için dört yıl önce bir web uygulaması yaptırmışlar. İlk yıl herkes memnun: ekranlar anında açılıyor. Bugün aynı uygulamada sipariş listesi on beş saniyede geliyor, ay sonu raporu çalışırken satış ekibi sipariş giremiyor, müşteri aramasında ise harf yazdıkça ekran donuyor. Kimse koda dokunmamış. Değişen tek şey, tablolardaki satır sayısı: birkaç bin siparişten birkaç yüz bine.
Bu durumda ilk akla gelen çözüm daha güçlü bir sunucudur. Bazen işe yarar, ama çoğu zaman sorunu birkaç ay erteler ve aylık faturayı kalıcı olarak yükseltir. Yavaşlamanın nedeni genellikle donanım değildir; yazılımın az veriyle sorun çıkarmayan, çok veriyle ağırlaşan birkaç alışkanlığıdır. Aşağıdaki yedi nokta, geliştiricinizle konuşurken sırayla sorabileceğiniz şeylerdir.
1. Önce ölçün: hangi ekran, ne kadar, kimde?
"Sistem yavaş" bir şikâyettir, iş tanımı değildir. Düzeltmeye başlamadan önce üç şeyi yazıya geçirin: hangi ekranlar yavaş, kaç saniye sürüyor ve bu herkeste mi yoksa belirli kullanıcılarda mı oluyor.
Kullanıcılardan bir hafta boyunca yavaş buldukları ekranları not etmelerini isteyin. Geliştirici de sunucu tarafında en uzun süren istekleri ve sorguları kayıtlardan çıkarsın. İki liste çoğu zaman aynı üç dört ekranı gösterir. Yavaşlığın büyük kısmı birkaç noktadan gelir; her yeri birden elden geçirmeye gerek yoktur.
Bu ölçüm, işin sonunda da gerekir. "Hızlandı mı?" sorusunun cevabı his değil, önceki ve sonraki saniyeler olmalıdır.
2. Listeler her şeyi birden mi getiriyor?
En sık görülen neden budur. Sipariş listesi ekranı ilk yapıldığında bütün siparişleri getirip ekrana dizmek kolaydı; iki yüz satırda kimse fark etmedi. İki yüz bin satırda aynı ekran, kullanıcının bakmayacağı kayıtları da veritabanından çekip tarayıcıya taşımaya çalışır.
Çözüm sayfalamadır: ekran ilk açılışta yalnızca son elli kaydı getirir, gerisi kullanıcı istedikçe gelir. Varsayılan bir tarih aralığı da aynı işi görür; çoğu kullanıcı zaten bu ayın siparişlerine bakar.
Aynı sorun açılır listelerde de görülür. Bütün müşterileri içeren bir seçim kutusu, müşteri sayısı arttıkça her formun açılışını yavaşlatır. Yazdıkça arayan bir kutu bu yükü kaldırır.
3. Aramalar ve filtreler için dizin var mı?
Veritabanı dizini, bir kitabın arkasındaki konu dizinine benzer. Dizin yoksa veritabanı aradığınız siparişi bulmak için tablonun bütün satırlarını baştan sona okur. Tablo küçükken bu fark edilmez; büyüdükçe her arama biraz daha uzar.
Dizinler genellikle ilk sürümde yalnızca en belirgin alanlara konur. Sonradan eklenen filtreler (bölgeye göre, temsilciye göre, duruma göre) çoğu zaman dizinsiz kalır. Birinci maddede çıkan yavaş sorgular listesi, hangi alanlara dizin gerektiğini doğrudan gösterir.
Bu, en az emekle en büyük farkı yaratan düzeltmedir. Bununla birlikte her alana dizin koymak da doğru değildir; her dizin kayıt eklemeyi biraz yavaşlatır. Hangi alanların gerçekten arandığına bakılarak karar verilir.
4. Bir ekran açılırken kaç sorgu çalışıyor?
Sipariş listesinde her satırın yanında müşteri adı, temsilci adı ve son ödeme tarihi görünüyorsa, yazılım bunları iki şekilde getirebilir: hepsini tek seferde ya da her satır için ayrı ayrı. İkinci yolda elli satırlık bir liste yüz elli ayrı sorgu demektir.
Geliştirme sırasında, birkaç kayıtla çalışırken bu fark görünmez. Canlıda her sorgunun süresi kısa olsa bile toplamı saniyeleri bulur. Çözüm, ilgili verinin toplu olarak tek sorguda çekilmesidir; ekranın görünüşü değişmez, yalnızca arkadaki iş azalır.
Geliştiricinize sorabileceğiniz basit soru şudur: "Bu ekran açılırken veritabanına kaç kez gidiyoruz?" Cevap yüzlerle ifade ediliyorsa neden bulunmuştur.
5. Raporlar canlı sistemin üzerinde mi çalışıyor?
Ay sonu raporu milyonlarca satırı toplayıp gruplar. Bu iş, sipariş girilen veritabanının üzerinde ve mesai saatinde yapılırsa, rapor bitene kadar herkes bekler. Toptancı örneğindeki "rapor çalışırken sipariş girilemiyor" şikâyeti tam olarak budur.
Üç yol vardır ve birbirini dışlamaz. Ağır raporlar gece çalıştırılıp sonucu saklanabilir; sabah açan kişi hazır sonucu görür. Sık bakılan toplamlar (günlük ciro, temsilci bazında satış) her seferinde baştan hesaplanmak yerine özet tablolarda tutulabilir. Veri gerçekten büyükse raporlar, canlı veritabanının salt okunur bir kopyasından beslenir.
Hangi raporun ne kadar güncel olması gerektiğini siz bilirsiniz. Dünkü veriyle yetinen bir rapor için canlı sistemi yormanın anlamı yoktur.
6. Eski veri hâlâ her sorgunun içinde mi?
Dört yıl önceki kapanmış siparişler, bugünkü sipariş listesinin bir parçası olmak zorunda değildir. Ama çoğu sistemde aynı tabloda dururlar ve her arama onları da tarar.
Arşivleme, veriyi silmek anlamına gelmez. Belirli bir süreden eski ve kapanmış kayıtlar ayrı bir tabloya taşınır; günlük ekranlar yalnızca güncel veriyle çalışır, eski kayıtlara ihtiyaç olduğunda "arşivde ara" seçeneğiyle ulaşılır. Sürenin ne olacağına muhasebe ve yasal saklama yükümlülükleriyle birlikte karar verilmelidir.
İşlem kayıtları, bildirim geçmişi ve hata kayıtları gibi kendiliğinden büyüyen tablolar da burada gözden geçirilir. Bunlar çoğu zaman asıl iş verisinden daha hızlı şişer.
7. Dosyalar ve görseller nerede duruyor?
Ürün fotoğrafları, taranmış irsaliyeler ve PDF teklifler veritabanının içinde ya da uygulamayla aynı diskte tutuluyorsa, hem yedekleme uzar hem de sayfalar ağırlaşır. Ürün listesinde her satır için telefondan çekilmiş birkaç megabaytlık fotoğrafın gösterilmesi, bağlantısı yavaş olan kullanıcıda ekranı kilitler.
Dosyaların ayrı bir depolama alanında tutulması ve listelerde küçültülmüş görsellerin kullanılması yeterlidir. Fotoğrafın aslı, kullanıcı üzerine tıkladığında açılır.
Sunucu ne zaman gerçekten yetmez?
Yukarıdaki noktalar düzeltildikten sonra da yavaşlık sürüyorsa ve ölçümler sunucunun belleğinin ya da işlemcisinin gün boyu sınırda çalıştığını gösteriyorsa, donanımı büyütmek doğru karardır. Sıra önemlidir: önce yazılımın gereksiz yaptığı iş azaltılır, sonra kalan iş için gereken donanım alınır. Tersi yapıldığında aynı gereksiz iş daha pahalı bir makinede çalışmaya devam eder.
Kısaca
- Yavaş ekranları ve sürelerini yazın; düzeltmeden önce ve sonra ölçün.
- Listeler sayfa sayfa gelsin, varsayılan bir tarih aralığı olsun.
- Aranan ve filtrelenen alanlarda dizin olup olmadığını kontrol ettirin.
- Bir ekranın açılırken kaç sorgu çalıştırdığını sorun.
- Ağır raporları gece çalıştırın, özet tablolardan ya da okuma kopyasından besleyin.
- Kapanmış eski kayıtları arşive taşıyın, silmeyin.
- Dosyaları ayrı depolayın, listelerde küçük görsel kullanın.
Bu yedi noktanın çoğu yazılımı baştan yazmayı gerektirmez; birkaç haftalık hedefli bir çalışmayla çözülür. İyi haber şu ki veri büyümesi öngörülebilir bir şeydir. Yılda bir kez aynı ölçümü yapmak, yavaşlığı kullanıcılar şikâyet etmeden önce yakalamaya yeter.
Yazılım bakım ve destek hizmetimizde yavaş açılan sayfaları, sorguları ve ekranları ölçüyor, darboğazları bulup gideriyoruz.
Bu konuda yaptığımız iş: Özel Yazılım Geliştirme
Böyle bir proje mi planlıyorsun?
10 adımda planla