Aranıza yeni katılmış bulunmaktayım, İlk mesajım bu.
Bu işi biraz kurcaladım, Sonunda ağ yavaşlığının nedenini uygulama/araştırma gözlemleyerek çözdüm
Firebird Veritabanı gerçekten harika, 3 yıldan beridir Kurumsal olarak kullanıyorum. aksini iddia eden birşeyden anlamıyor demektir.
Hem ücretsiz, hem de bir sürü desteği bulunuyor, bu konuda bağımsız developerları seviyorum.
Bir kurumda personel kayıtlarını tutmaktayım, Kayıtlarımı performans için iki adet veritabanına böldüm
Birincisi TXT tabanlı yani normal kayıtlar gibidir sadece iki kolonda Blob alan bulunuyor her biri 32 kb yi geçmeyen personel resimleri mevcut bu VT =300M civarında.
ikinci veritabanım ise neredeyse 4000 adet belge pdf xls jpeg barındırıyor bu VT ise 1GB oldu.
ilk veritabanımı master, ikinci veritabanımı Detail olarak lüzum olduğunda Master
kaydın tablosunu bağlayıp işlem yapıyorum, iki adet connection ile master detail yapı kurdum , böylece işim bitince close edip eski kaldığım hızdan devam ediyorm.
Projem 127.0.0.1 üzerinde 4 saniyede açılıyor, Modem içi Local ağ üzerinde ise 30 saniye WAN ağ üzerinde 5 Dakikada açılıyor bende de hız yavaşlaması var fakat çok değil.
Bu nedenle gereksiz queryleri tabloları close ederek hızı arttırma yoluna gittim çok az değişiklik oldu.
object inspectorda Query ve tablolardaki FetchRows denen alan bulunuyor, bu alan veritabanındaki verilerin gösterim Rowları yani sıralarıdır.
Bunun artması Örneğin 100.000 kaydı olan VT de verileri göstermek için bunu 25.000 yaptığımda hafif kasma ,50.000 row yaptığımızda biraz daha fazla yarı yarıya kasmaya başlıyor 75.000 yaptığımda ve üzeri süre uzuyor. neyse bunu not ettim bi kenara.
Bunun Dbgridde gösterimini 100 row olarak ayarladığımızda VT hemencecik açıldı. fakat tekrar 100.000 yaptığımda malesef kaplumağa gibi oldu geç açıldı, bunları iki üç ağ üzerinde deneyerek test ettim. bunu da not ettim yazdım kenara.
kodlarımı kontrol ederken form yüklenirken FetchRows ve Refresh edildiğinde ikisinin orantılı yavaşlattığını farkettim,FetchRows yüksek olursa VT den veri çekilip hafızaya ayarladığınız fetch rows değeri kadar yer ayırtıyor bu nedenle yavaşlatıyor, Refresh ise Yüklendikten sonra VT den çekilen veri işini ekran kartında yeniden gösterime sokuyor. bu da yavşlatma sebebi. Derhal Refresh kullanımının olduğu yerleri gözden geçirip silince Programın açılışı gözle görülür bir şekilde azaldı.
Bir de Resim bulunan tablolarda FetchRows u mümkün olduğu kadar minimum tutmak gerekir, dolaysıyla resimler de hafızaya load ediliyor, ve yavaşlamaya başlıyor, fakat bu sefer end of file (eof) ile ilgili işlem yaptığımızda kaydın gerisini DBGRID içinde görememe durumu oluşuyor, şimdi ikilem durumunda kaldım, FetchRows u arttırırsam , arttırdığım miktar kadar load olacak Yavaşlamaya sebebiyet verecek.
FetchRowsu düşürürsem EOF ile ilgili dosya sonu döngüsel işlerin dbgridde yarım gösterecek örneğin 100 kaydım var FetchRows u 80 ye ayarladım, while not query.eof do döngüsü ile 80. kayda gelince 81 den sonraki kayıtlar yeni yeni gözükmeye başlıyor, çünkü form ilk açılınca FetchRow 80 olduğundan end of file 80. kayıttadır diye bildirmiştik yani Dbgridin rowları 80 dir, 81. ve sonrası kaydı dbgride görünmez. ancak page down yapınca 80'er 80'er göstermeye, veya döngü ile göster deyince 80 den sonrakileri göstermeye başlıyor
Bunların yavaşlatmaya etkisi bulunuyor, tespit ettim. isteyen Querylerin veya Tabloların FetchRows değeri ile ne dediğimi test edebilirsiniz..
Blob Alan sayısı, veri miktarı, Database boyutu ile ilişkilidir.
(16-01-2021, Saat: 15:38)COMMANDX Adlı Kullanıcıdan Alıntı: Aranıza yeni katılmış bulunmaktayım, İlk mesajım bu.
Bu işi biraz kurcaladım, Sonunda ağ yavaşlığının nedenini uygulama/araştırma gözlemleyerek çözdüm
Firebird Veritabanı gerçekten harika, 3 yıldan beridir Kurumsal olarak kullanıyorum. aksini iddia eden birşeyden anlamıyor demektir.
Hem ücretsiz, hem de bir sürü desteği bulunuyor, bu konuda rusları seviyorum.
Bir kurumda personel kayıtlarını tutmaktayım, Kayıtlarımı performans için iki adet veritabanına böldüm
Birincisi TXT tabanlı yani normal kayıtlar gibidir sadece iki kolonda Blob alan bulunuyor her biri 32 kb yi geçmeyen personel resimleri mevcut bu VT =300M civarında.
ikinci veritabanım ise neredeyse 4000 adet belge pdf xls jpeg barındırıyor bu VT ise 1GB oldu.
ilk veritabanımı master, ikinci veritabanımı Detail olarak lüzum olduğunda Master
kaydın tablosunu bağlayıp işlem yapıyorum, iki adet connection ile master detail yapı kurdum , böylece işim bitince close edip eski kaldığım hızdan devam ediyorum.
Projem 127.0.0.1 üzerinde 4 saniyede açılıyor, Modem içi Local ağ üzerinde ise 30 saniye WAN ağ üzerinde 5 Dakikada açılıyor bende de hız yavaşlaması var fakat çok değil.
Bu nedenle gereksiz queryleri tabloları close ederek hızı arttırma yoluna gittim çok az değişiklik oldu.
object inspectorda Query ve tablolardaki FetchRows denen alan bulunuyor, bu alan veritabanındaki verilerin gösterim Rowları yani sıralarıdır.
Bunun artması Örneğin 100.000 kaydı olan Veri Tabanında verileri göstermek için bunu 25.000 yaptığımda azıcık kasma ,50.000 row yaptığımızda biraz daha fazla kasma, 75.000 ve üzeri Açılış süreleri uzuyor. bunu not ettim bi kenara.
Bunun Dbgridde gösterimini 100 row olarak ayarladığımızda VT hemencecik açıldı. fakat tekrar 100.000 yaptığımda malesef kaplumağa gibi oldu geç açıldı, bunları iki üç ağ üzerinde deneyerek test ettim. bunu da not ettim yazdım kenara.
kodlarımı kontrol ederken form yüklenirken FetchRows ve Refresh edildiğinde ikisinin orantılı yavaşlattığını farkettim,FetchRows yüksek olursa VT den veri çekilip hafızaya ayarladığınız fetch rows değeri kadar yer ayırtıyor bu nedenle yavaşlatıyor, Refresh ise Yüklendikten sonra VT den çekilen veri işini ekran kartında yeniden gösterime sokuyor. bu da yavşlatma sebebi. Derhal Refresh kullanımının olduğu yerleri gözden geçirip silince Programın açılışı gözle görülür bir şekilde azaldı.
Bir de Resim bulunan tablolarda FetchRows u mümkün olduğu kadar minimum tutmak gerekir, dolaysıyla resimler de hafızaya load ediliyor, ve yavaşlamaya başlıyor, fakat bu sefer end of file (eof) ile ilgili işlem yaptığımızda kaydın gerisini DBGRID içinde görememe durumu oluşuyor, şimdi ikilem durumunda kaldım, FetchRows u arttırırsam , arttırdığım miktar kadar load olacak Yavaşlamaya sebebiyet verecek.
FetchRowsu düşürürsem EOF ile ilgili dosya sonu döngüsel işlerin dbgridde yarım gösterecek örneğin 100 kaydım var FetchRows u 80 e ayarladım, while not query.eof do döngüsü ile 80. kayda gelince 81 den sonraki kayıtlar yeni yeni gözükmeye başlıyor, çünkü form ilk açılınca FetchRow 80 olduğundan end of file 80. kayıttadır diye bildirmiştik yani Dbgridin rowları 80 dir, 81. ve sonrası kaydı dbgride görünmez. ancak page down yapınca 80'er 80'er göstermeye, veya döngü ile göster deyince 80 den sonrakileri load edip göstermeye başlıyor
isteyen Querylerin veya Tabloların FetchRows değeri ile ne dediğimi test edebilirsiniz..
Program açılışta lazım olacak kadar veri yükleyin, mesela sql de ilk 20 kaydı getir gibi (select * from tablo where xxxx=1 order by yyyy rows 20)gibi
Blob Binary alanlar veri miktarı, Database boyutu Refresh etmeler ve FetchRows ayarı Veri Tabanının hızını etkileyen sebeplerdir.
)
