Uzak ağ veritabanı işlemlerini hızlandırmak
- White Rose
- Üye
- Mesajlar: 726
- Kayıt: 06 Tem 2005 09:41
- Konum: Güneyden
- İletişim:
Uzak ağ veritabanı işlemlerini hızlandırmak
s.a.
Arkadaşlar, statip IP üzerinden uzak ağ veritabanına bağlanarak, dosyalar üzerinde işlem yapıyorum. Ancak bildiğiniz gibi olaylar yavaş işliyor. Dosyanın açılması, insert, post olayları, sorgulamalar yavaş çalışıyor. Bunu hızlandırmanın yolları, teknikleri nelerdir. Yardımcı olabilirseniz sevinirim. Teşekkürler.
Arkadaşlar, statip IP üzerinden uzak ağ veritabanına bağlanarak, dosyalar üzerinde işlem yapıyorum. Ancak bildiğiniz gibi olaylar yavaş işliyor. Dosyanın açılması, insert, post olayları, sorgulamalar yavaş çalışıyor. Bunu hızlandırmanın yolları, teknikleri nelerdir. Yardımcı olabilirseniz sevinirim. Teşekkürler.
a.s.
program direk uzak vt ye bağlanırsa dediğiniz gibi yavaş olur. genelde sql ve sp leri kullanarak (TABLE bileşeni kullanmadan), sadece ihtiyacınız olan kayıtları çekerek hız konusunda bir artış sağlayabilirsiniz.
ancak asıl yapmanız gereken şöyle bişey olmalı.
http://www.astatech.com/index.asp
kolay gelsin.
program direk uzak vt ye bağlanırsa dediğiniz gibi yavaş olur. genelde sql ve sp leri kullanarak (TABLE bileşeni kullanmadan), sadece ihtiyacınız olan kayıtları çekerek hız konusunda bir artış sağlayabilirsiniz.
ancak asıl yapmanız gereken şöyle bişey olmalı.
http://www.astatech.com/index.asp
kolay gelsin.
Duyduğun Şeylerin Söylediklerim Olduğuna Eminim Ama
Anladığın Şeylerin Anlatmak İstediklerim Olduğuna Emin Değilim
Anladığın Şeylerin Anlatmak İstediklerim Olduğuna Emin Değilim
- White Rose
- Üye
- Mesajlar: 726
- Kayıt: 06 Tem 2005 09:41
- Konum: Güneyden
- İletişim:
Selamlar,
Tavsiyemiz şu olacaktır. Bu tavsiyeler LAN'lar çok geçerli değil ama 5,000 Kullanıcılı bir LAN'ınız varsa orası için de geçerli olacaktır.
Olay şu, Network trafiğini oluşturmamak. Çok kullanıcılı sistemlerde, ana makinaya bağlı lan istemcilerin, ana makinadan çektikleri veri ne kadar büyürse o kadar fazla trafik oluşur ve genel sistem işleyişi yavaşlar.
Bunu WAN'larda daha net gözlemleyebilirsiniz. 100 MBit bağlı olan LAN'larda SELECT * FROM TABLO1 şeklinde çalışan bir SQL cümlesinin sonucunun gelişi, WAN'larda çok daha vahim olacaktır.
Bu işlem Wireless bir networkde bile sorun oluşturur (ki 54 MBit'den bahsediyorum) Hele hele internet üzerinden (ortalama 2 MBit ile bağlı olduğunuzu varsaysak bile) 100 MBit bağlı LAN'a göre tam 50 Kat yavaş çalışır.
Nedeni sizin makinanız yada Server'ın meşguliyetinden çok Hat hızlarınızdır.
Bu durumda ne yapmak gerekir.
1. Delphi içinden Mümkün olduğunca Query'er veya tablolar açıp, For Next veya While döngüleri kurmamak lazım. Bu tür işler olduğunda, bunları SP'lere yüklemek ve hesaplamaları onların üzerinden gerçekleştirmek lazım. Bu size ayrıca, Kullanıcı arayüzlerinde rahatlama sağlar. Nasıl mı? Şöyle sağlar. Bir çeşit vade hesaplamaları yaptığınız bir ödeme veya alacak analizi yaptığınız işlem olsun. İlla ki bu tür durumlarda döngü kurarak eşleştirme yapmanız gerekir. Eğer siz bunu delphi ayağında yaparsanız ve update gibi cümlelerinizi yine Delphi ayağında yaparsanız, her nextte (hemen hemen her Nextte) serverla temas kurmanız gerekir. Bunun yerine bu tür bir işi, Server'a yıkarsanız (bir SP yazarsanız) Delphi, sadece sonuçları gösteren bir arayüz durumuna gelir. Aynı SP'yi bir başka Web servisinde veya HTML hazırlanan ekranlarda (bir başka dilde bir başka programlama biriminde de ) halledebilirsiniz. Böylelikle aynı rutinleri kullanan hem desktop hem de WEB arayüzleriniz olur.
2. Veri kümesini tek seferde topluca getirmek yerine, lazım olan veriyi lazım olduğu zamanda ve nokta atışı diyebileceğimiz şekilde çekmek olacaktır. Yani aslında Network trafiğini azaltarak uzak ağ bağlantılarında verimliliğinizi arttırırsınız. Bu da size performans olarak geri döner.
Client/Server uygulamalarda ortaya çıkan önemli sorunlardan biri de budur. Network trafiği. Bir çok programcı bunun farkında bile değildir. Ne zaman ki WAN çalışmaya başlarlar o zaman farkına varırlar. Biz de zamanında o yollardan geçtik
Bu iki konuya dikkat ederseniz, sıkıntılarınızın büyük bir çoğunluğunu aşarsınız ve performans sorununuz kalmaz. Ama kaçamayacağınız yerler de olacaktır. O zaman mantıkları irdelemeniz gerekir. Yani yapılan işi değiştirebilirsiniz bu tür durumlarda.
Kolay Gelsin
Tavsiyemiz şu olacaktır. Bu tavsiyeler LAN'lar çok geçerli değil ama 5,000 Kullanıcılı bir LAN'ınız varsa orası için de geçerli olacaktır.
Olay şu, Network trafiğini oluşturmamak. Çok kullanıcılı sistemlerde, ana makinaya bağlı lan istemcilerin, ana makinadan çektikleri veri ne kadar büyürse o kadar fazla trafik oluşur ve genel sistem işleyişi yavaşlar.
Bunu WAN'larda daha net gözlemleyebilirsiniz. 100 MBit bağlı olan LAN'larda SELECT * FROM TABLO1 şeklinde çalışan bir SQL cümlesinin sonucunun gelişi, WAN'larda çok daha vahim olacaktır.
Bu işlem Wireless bir networkde bile sorun oluşturur (ki 54 MBit'den bahsediyorum) Hele hele internet üzerinden (ortalama 2 MBit ile bağlı olduğunuzu varsaysak bile) 100 MBit bağlı LAN'a göre tam 50 Kat yavaş çalışır.
Nedeni sizin makinanız yada Server'ın meşguliyetinden çok Hat hızlarınızdır.
Bu durumda ne yapmak gerekir.
1. Delphi içinden Mümkün olduğunca Query'er veya tablolar açıp, For Next veya While döngüleri kurmamak lazım. Bu tür işler olduğunda, bunları SP'lere yüklemek ve hesaplamaları onların üzerinden gerçekleştirmek lazım. Bu size ayrıca, Kullanıcı arayüzlerinde rahatlama sağlar. Nasıl mı? Şöyle sağlar. Bir çeşit vade hesaplamaları yaptığınız bir ödeme veya alacak analizi yaptığınız işlem olsun. İlla ki bu tür durumlarda döngü kurarak eşleştirme yapmanız gerekir. Eğer siz bunu delphi ayağında yaparsanız ve update gibi cümlelerinizi yine Delphi ayağında yaparsanız, her nextte (hemen hemen her Nextte) serverla temas kurmanız gerekir. Bunun yerine bu tür bir işi, Server'a yıkarsanız (bir SP yazarsanız) Delphi, sadece sonuçları gösteren bir arayüz durumuna gelir. Aynı SP'yi bir başka Web servisinde veya HTML hazırlanan ekranlarda (bir başka dilde bir başka programlama biriminde de ) halledebilirsiniz. Böylelikle aynı rutinleri kullanan hem desktop hem de WEB arayüzleriniz olur.
2. Veri kümesini tek seferde topluca getirmek yerine, lazım olan veriyi lazım olduğu zamanda ve nokta atışı diyebileceğimiz şekilde çekmek olacaktır. Yani aslında Network trafiğini azaltarak uzak ağ bağlantılarında verimliliğinizi arttırırsınız. Bu da size performans olarak geri döner.
Client/Server uygulamalarda ortaya çıkan önemli sorunlardan biri de budur. Network trafiği. Bir çok programcı bunun farkında bile değildir. Ne zaman ki WAN çalışmaya başlarlar o zaman farkına varırlar. Biz de zamanında o yollardan geçtik

Bu iki konuya dikkat ederseniz, sıkıntılarınızın büyük bir çoğunluğunu aşarsınız ve performans sorununuz kalmaz. Ama kaçamayacağınız yerler de olacaktır. O zaman mantıkları irdelemeniz gerekir. Yani yapılan işi değiştirebilirsiniz bu tür durumlarda.
Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
- White Rose
- Üye
- Mesajlar: 726
- Kayıt: 06 Tem 2005 09:41
- Konum: Güneyden
- İletişim:
-
- Kıdemli Üye
- Mesajlar: 1026
- Kayıt: 11 Şub 2005 02:12
- Konum: İstanbul
Bütün verileri oradan oraya çekmek yerine "uzak masaüstü bağlantısı" yolu ile programın çalışmasını sağlayabilirsiniz. Bu teorik olarak daha hızlı bir çalışma sağlayacaktır.
Bunun yanında Firebird için Fibplus bileşenlerini kullanmanız network trafiğini azaltacaktır. IBX bileşenleri bir hayli yavaş çalışıyor ağ ortamında.
Bunun yanında Firebird için Fibplus bileşenlerini kullanmanız network trafiğini azaltacaktır. IBX bileşenleri bir hayli yavaş çalışıyor ağ ortamında.
Fb ile uzak bağlantı ve hız işine bizde epey debelenmiştik. Uzak bağlantılı programlarda local makine de veya local ağ daki mantıkla hareket ederseniz cırmalıyorsunuz.
Yapılacak iş şu... vt ye bağlan. ihtiyacın olan veriyi çek.
örneğin 20.000 kayıt olan bir table yi db grid de göstermek yerine arama yaptırıp ihtiyacın olduğu kayıtların getirtilmesi gibi...
dblookupcombo ları mümkün mertebe kullanmamak.
select * from felanfilan yerine select SIRA, AD, SOYAD from felanfilan where AD = 'şu bu' gibi sql cümlecikleri kullanmak. (ihtiyaç olan field ları ve kayıtları çekmek)
bunu şöyle düşünün bir dosyanız var 20 000 kayıt var ve bu kayıtların toplamı diyelim ki 2 mg.. siz select * from dediğiniz anda netten 2 mb bir dosya indirme süresi neyse bu süreyi burda da beklemek zorundasınız.
ancak where koşulu koyup kayıtları sınırladığınız anda gelen kayıtlar kesinlikle 2 mb ın altında olacaktır. bu da hız demektir.
hesap kitap işlerini olabildiğince server tarafında sp veya view lerle halletmek. Server a ne kadar iş yıkarsanız program o kadar hızlanıyor. Exe tarafında hesap kitap işi yapmayın.
http://www.sibergaleri.com
bu sitenin verileri çeşitli şehirlerden bir exe programı tarafından giriliyor. exe ve site firebird kullanıyor. ne hız nede başka bir sorun var. veriler şimdilik az fakat çok olsada bişe farketmez.
Yapılacak iş şu... vt ye bağlan. ihtiyacın olan veriyi çek.
örneğin 20.000 kayıt olan bir table yi db grid de göstermek yerine arama yaptırıp ihtiyacın olduğu kayıtların getirtilmesi gibi...
dblookupcombo ları mümkün mertebe kullanmamak.
select * from felanfilan yerine select SIRA, AD, SOYAD from felanfilan where AD = 'şu bu' gibi sql cümlecikleri kullanmak. (ihtiyaç olan field ları ve kayıtları çekmek)
bunu şöyle düşünün bir dosyanız var 20 000 kayıt var ve bu kayıtların toplamı diyelim ki 2 mg.. siz select * from dediğiniz anda netten 2 mb bir dosya indirme süresi neyse bu süreyi burda da beklemek zorundasınız.
ancak where koşulu koyup kayıtları sınırladığınız anda gelen kayıtlar kesinlikle 2 mb ın altında olacaktır. bu da hız demektir.
hesap kitap işlerini olabildiğince server tarafında sp veya view lerle halletmek. Server a ne kadar iş yıkarsanız program o kadar hızlanıyor. Exe tarafında hesap kitap işi yapmayın.
http://www.sibergaleri.com
bu sitenin verileri çeşitli şehirlerden bir exe programı tarafından giriliyor. exe ve site firebird kullanıyor. ne hız nede başka bir sorun var. veriler şimdilik az fakat çok olsada bişe farketmez.
Ben uzak veritabanına bağlanmak için size farklı bir yol tavsiye edecem.Firbird direkt bağlantıda sorun yaratıyor.Önce firebird bir application server(Web server) yazın.Bunu yayınlayın sonrasında buna client bağlantı kurun. Çok hızlı çalışırsınız. Client kurulumu sorunu yaşamazsınız. Port açmak gibi sorunlar yaşamazsınız.. Ayrıca sık kullandığınız stringleri client tarafında yerel veritabanında tutup bunu integer degerlerini göndeririseniz yükü azaltmış olursunuz. Özellikle serverle haberleşmede göndereceğiniz paketin yükünü hesaplayıp programı ona göre organize ederseniz daha iyi sonuç alırsınız.