Epin Yazılımında Rapor Dışa Aktarımı Neden Tam O Anda Çöküyor? Aylık Ciro Raporunu Alamamanın Arkasındaki Bellek Duvarını Sana Kimse Göstermedi

Ay sonu geldiğinde panelden ciro raporunu indirmek istersin, dışa aktar tuşuna basarsın ve sayfa bir süre döndükten sonra boş bir hata ya da yarım inmiş bir dosyayla karşılaşırsın. Çoğu satıcı bu noktada raporlama modülünü suçlar, hatta "bu e-pin yazılımı kötü yazılmış" diye düşünür. Gerçek çok daha sıkıcı ve çok daha düzeltilebilir: raporun kendisi doğrudur, onu üretmeye çalışan süreç sunucunun izin verdiği sınırların dışına taşmaktadır.

Bu yazıda dışa aktarım hatalarının neden tam olarak işin büyüdüğü ay ortaya çıktığını, hangi dört sınırın sırayla devreye girdiğini ve neden "limiti artır" çözümünün belirli bir noktadan sonra işe yaramadığını anlatacağım. Ardından ciddi bir dijital ürün satış scriptinin bu işi nasıl tamamen farklı bir mimariyle çözdüğünü göreceksin.

Rapor küçükken çalışıyordu, çünkü sınırlar henüz görünmüyordu

İlk aylarda üç yüz siparişin vardı ve dışa aktarım bir saniyede bitiyordu. Bugün otuz bin satırın var ve aynı kod, tüm satırları önce belleğe topluyor, sonra bir dosya nesnesine dönüştürüyor, sonra diske yazıyor. Yani aynı veri bellekte en az iki, çoğu zaman üç kopya halinde duruyor. Otuz bin satırlık bir veri kümesi ham haliyle mütevazı görünse de, nesneye dönüştürülmüş hali onlarca kat yer kaplar.

Bu yüzden dışa aktarım hatası kademeli değil, ani gelir. Yirmi dört bin satırda sorunsuz çalışan işlem, yirmi altı binde hiç çalışmaz. Arada bir uyarı, bir yavaşlama evresi yoktur; çünkü aşılan şey bir performans eşiği değil, kesin bir bellek tavanıdır. Sunucu süreci öldürür ve tarayıcıya çoğu zaman anlamlı bir hata bile ulaşmaz.

Dört ayrı sınır var ve hepsi farklı belirti verir

Dışa aktarımın yolunda üst üste dizilmiş dört kapı bulunur. Birincisi uygulamanın bellek sınırı; aşıldığında işlem sessizce ölür, ekranda boş sayfa görürsün. İkincisi çalışma süresi sınırı; aşıldığında genellikle zaman aşımı mesajı alırsın. Üçüncüsü web sunucusunun ters proxy zaman aşımıdır; burada tarayıcıya ağ geçidi hatası düşer, oysa arkada işlem hâlâ çalışıyor olabilir. Dördüncüsü ise geçici dosya dizininin yazma izni ve disk alanıdır.

Teşhisin ilk adımı hangi kapıya çarptığını belirlemektir, çünkü çözümleri birbirinden tamamen farklıdır. Boş beyaz sayfa bellek; "süre aşıldı" mesajı çalışma süresi; 502 veya 504 benzeri hata ise proxy katmanı demektir. Yarım inen ve açılmayan dosya çoğunlukla çıktının arasına bir uyarı metninin sızdığını gösterir.

Neden "bellek limitini artır" kalıcı bir çözüm değil?

Limiti iki katına çıkardığında rapor yeniden çalışır ve sorun çözülmüş gibi görünür. Ancak yaptığın şey duvarı yıkmak değil, birkaç ay ileri taşımaktır. Üstelik bu yaklaşımın gizli bir bedeli vardır: yüksek bellek limiti yalnız rapor için değil, sitenin tüm istekleri için geçerlidir. Yoğun bir saatte birkaç ağır istek aynı anda gelirse sunucu tamamen tıkanır ve dışa aktarım sorunu bir anda site erişilebilirlik sorununa dönüşür.

Doğru yaklaşım, raporun bellekte biriktirilmeden üretilmesidir. Veritabanından satırlar parça parça okunur, her parça anında dosyaya yazılır ve bellekten atılır. Bu yöntemde beş yüz satırla beş yüz bin satır arasında bellek açısından fark yoktur; yalnızca süre uzar. Süreyi de arka plan görevine taşıyarak çözersin.

Sorun raporda değil, sorguda olabilir

Bazı kurulumlarda dışa aktarım kodu kusursuzdur ama arkasındaki sorgu birkaç tabloyu indekssiz birleştirir. Bu durumda veritabanı yanıtı dakikalarca gecikir ve uygulama daha ilk satırı alamadan süre dolar. Belirtisi ayırt edicidir: rapor küçük tarih aralığında bile yavaştır, sayfa sayısı azaltıldığında düzelmez.

Burada yapılacak iş rapor modülüne dokunmak değil, filtrelenen alanlara uygun indeksleri eklemektir. Tarih aralığı, sipariş durumu ve bayi kimliği üçlüsü raporlarda neredeyse her zaman birlikte kullanılır; bu üçlüye uygun bir bileşik indeks çoğu zaman saniyeler süren bir sorguyu milisaniyelere indirir. Sağlıklı bir e-pin satış yazılımı bu indeksleri kurulum sırasında hazır getirir, sonradan aramanı beklemez.

Türkçe karakter ve biçim bozulmaları neden hata sanılır?

Dosya iniyor ama içindeki ürün adları anlamsız karakterlerle dolu; ya da stok kodların tablo programında tarihe dönüşmüş. Bunlar teknik olarak "hata" değildir, sistem tam olarak kendisinden isteneni yapmıştır. Fakat işletme açısından rapor kullanılamaz durumda olduğu için hata olarak algılanır.

Çözüm iki tarafı da düşünmekten geçer. Çıktının başına doğru kodlama imzası eklenir, böylece tablo programı Türkçe karakterleri doğru okur. Uzun sayısal kodlar ise metin olarak işaretlenir, böylece otomatik biçimlendirme devreye girmez. Bu iki küçük dokunuş, destek ekibine düşen taleplerin şaşırtıcı bir kısmını doğrudan yok eder. Özellikler bölümünde raporlama tarafının hangi biçimlerde çıktı verdiğini inceleyebilirsin.

Doğru mimari: rapor bir sayfa isteği değil, bir iştir

Kritik zihinsel sıçrama şudur: büyük bir rapor, tarayıcının beklediği bir sayfa yanıtı olarak düşünülmemelidir. O bir iştir. Kullanıcı dışa aktar dediğinde sistem bir iş kaydı oluşturur, kullanıcıya "raporun hazırlanıyor" der ve sayfayı serbest bırakır. Arka planda çalışan işçi satırları parça parça yazar, iş bitince dosyayı saklar ve kullanıcıya bildirim düşer.

Bu kurguda dört sınırın hiçbiri seni bağlamaz. Tarayıcı beklemediği için proxy zaman aşımı anlamsızlaşır, bellek sabit kaldığı için satır sayısı önemsizleşir, arka plan görevinde süre limiti yoktur. Üstüne bir de ilerleme yüzdesi ve hata durumunda anlamlı bir mesaj ekleyebilirsin. Pinova raporlamayı bu yaklaşımla ele alır; büyük dökümler istek hattında değil iş hattında üretilir. Fiyat bölümünde hangi pakette hangi rapor derinliğinin geldiğini görebilirsin.

Raporlama, bir sistemin gerçek ölçeğini en açık gösteren yerdir; çünkü satış sayfası her zaman hızlıdır, asıl sınav ay sonu dökümündedir. Kurulumun bu sınavı geçiyor mu, en hızlı şekilde kendi verine yakın bir hacimle test ederek anlarsın. canlı demo üzerinden geniş tarih aralıklı bir rapor alıp akışın nasıl davrandığını gör, ardından sana uygun paketi seç.