fb arkada neler çeviriyor ?

[sadettinpolat]

uzaktaki bir fb server'a (1.5.2) gprs modem üzerinden bağlanıp işlem yapıyorum. db ye bağlanması makul bir süre ama delete , update, insert gibi bir sorgu çalıştırmak çok yavaş. yaklaşık 30 saniye falan sürüyor execsql komutunun çalışıp işini bitirmesi. gönderdiğim sql insert into gibi basit bir veri olmasına rağmen bu durum zarfında serverla client arasında giden bilginin boyutu haddinden fazla. bazen ise arada duraklamalar oluyor ki bu kısma hiçbir mana veremiyorum. ne oluyor bu arada? aynı süre zarfında http://www.haber7.com u gayet rahat bir şekilde açabiliyorum.

select te ise geriye 1 kayıt dönmüş 50 kayıt dönmüş fark etmiyor. ikisinin süreside eşit. buda record uzunğunun çokta önemli olmadığını gösteriyor bana. fb arkada başka bişeler karıştırıyor ama ne olduğunu bulamadım.

mysql de ise bu süreler daha kısa. select işlemleri çok daha hızlı çalışıyor.

zebedee gibi bir tool kurup verileri sıkıştırarak karşıya göndermeyi denemedim ama bunun pek fazla etkili olacağını sanmıyorum zira giden gelen verilerin çok fazla bir yer işgal ettiğini düşünmüyorum.

bu yavaşlığın nedenini bir türlü çözemedim.

[Terminator]

uzaktaki bir fb server'a (1.5.2) gprs modem üzerinden bağlanıp işlem yapıyorum. db ye bağlanması makul bir süre ama delete , update, insert gibi bir sorgu çalıştırmak çok yavaş. yaklaşık 30 saniye falan sürüyor execsql komutunun çalışıp işini bitirmesi. gönderdiğim sql insert into gibi basit bir veri olmasına rağmen bu durum zarfında serverla client arasında giden bilginin boyutu haddinden fazla. bazen ise arada duraklamalar oluyor ki bu kısma hiçbir mana veremiyorum. ne oluyor bu arada? aynı süre zarfında http://www.haber7.com u gayet rahat bir şekilde açabiliyorum.

select te ise geriye 1 kayıt dönmüş 50 kayıt dönmüş fark etmiyor. ikisinin süreside eşit. buda record uzunğunun çokta önemli olmadığını gösteriyor bana. fb arkada başka bişeler karıştırıyor ama ne olduğunu bulamadım.

mysql de ise bu süreler daha kısa. select işlemleri çok daha hızlı çalışıyor.

zebedee gibi bir tool kurup verileri sıkıştırarak karşıya göndermeyi denemedim ama bunun pek fazla etkili olacağını sanmıyorum zira giden gelen verilerin çok fazla bir yer işgal ettiğini düşünmüyorum.

bu yavaşlığın nedenini bir türlü çözemedim.

Sadettin,
FB ün netwrok protokolü çağın gerisinde kalmış durumda, yeniden yazılıyor. FB icat edildiğinde ve sonrasında uzun yıllar WEB ya da geniş alan ağı gibi kavramlar yoktu. bağlantı sayıları ve mekanizmaları farklıydı.
Senin sorunun çözümüne gelince:
şimdilik zebede kullanabilirsin, o, iletişim paketlerini hem sıkıştırıp küçültüyor hem de şifreleyebilir güvenlik amaçlı olarak. ve ücretsiz bir IP tünel yazılımı.
GPRS modemler zaten çok yavaştır, yaklaşık dial-up hızındadır ve dial-up artık pek kullanılmıyor. EDGE çok daha hızlı.
Neler yapabilirsin:
1- client SQL hook/monitor tarzı bir uygulama ile FB iletişimini minimize ve optimize etmeye çalış. kompenentlerin çoğu sizin farkında olmadığınız bir sürü iletişim yapıyor birçok şeyi otomatikmiş gibi yansıtmak için.
2- Querylerini, sahalarını asgari tut. lazımolan sahaları getir sadece.
kullanmayacağın bilgiyi getirme ya da kulanacağın kadarını, serverda kestirerek getir.
3- Yeni FB ler çıkana kadar zebede kullan.

FB için kullanıcının nereden nasıl bağlandığının önemi yoktur, o sadece SQL hizmetini verir. buradaki sorun SQL iletişim yapılarının, bandın kapasitesini zorlayacak büyüklükte olması, geniş banda, lokal ağ hızına alışmış bonkör yazılımcıların, kısıtlı kaynaklar için hazırlıklı olmamasıdır.

Söylediklerimi bir dene, tecrübelerini burada herkesle paylaşabilirsin,
tekrar konuyu tartışabiliriz burada...

[Kuri_YJ]

...

select te ise geriye 1 kayıt dönmüş 50 kayıt dönmüş fark etmiyor. ikisinin süreside eşit. buda record uzunğunun çokta önemli olmadığını gösteriyor bana. fb arkada başka bişeler karıştırıyor ama ne olduğunu bulamadım.
...

Demişsiniz ama bu noktaya biraz daha dikkat edin. Şimdi belki sizin hızınız dolayısıyla 50 Kaydı anlayamıyor olabilirsiniz, ancak tut ki o 50 dediğiniz kayıt sayısı gerile 100,000 Kayıt döndürürse?

Ağda giden gelen bilginin çokluğu önem arz etmekte, onu göz ardı etmeyin, 1 kayıt ile 50 kayıt arasında çok fark vardır. Düşünsenize 1 Kaydı döndürmek için (atıyorum) 2 IP Paketi göndermesi yeterken, 50 Kayıt için 100 IP Paketi göndermesi gerekebilir (Yani tam olarak bu şekilde değil ama anlaşılabilmesi için bu şekilde örnekledim)

Kolay Gelsin

[Terminator]

...

select te ise geriye 1 kayıt dönmüş 50 kayıt dönmüş fark etmiyor. ikisinin süreside eşit. buda record uzunğunun çokta önemli olmadığını gösteriyor bana. fb arkada başka bişeler karıştırıyor ama ne olduğunu bulamadım.
...

Demişsiniz ama bu noktaya biraz daha dikkat edin. Şimdi belki sizin hızınız dolayısıyla 50 Kaydı anlayamıyor olabilirsiniz, ancak tut ki o 50 dediğiniz kayıt sayısı gerile 100,000 Kayıt döndürürse?

Ağda giden gelen bilginin çokluğu önem arz etmekte, onu göz ardı etmeyin, 1 kayıt ile 50 kayıt arasında çok fark vardır. Düşünsenize 1 Kaydı döndürmek için (atıyorum) 2 IP Paketi göndermesi yeterken, 50 Kayıt için 100 IP Paketi göndermesi gerekebilir (Yani tam olarak bu şekilde değil ama anlaşılabilmesi için bu şekilde örnekledim)

Kolay Gelsin

1 kayıtla 50 kayıt fetchi arasındaki performans farkını hissedemeyebilirsin
bazı durumlarda. kayıtın küçük sayısal sahalardan oluşuyorsa, fazla uzun string saha yoksa hız pek anlaşılmaz. yani 1 rowun fetchiyle 50 rowun fetchi arasında belki GPRS 48kpbs de 1 sn fark yaratır ki bu pek önemsenmeyebilir.
Sadettinin sorunu querylerin yapılandırılmasıyla ilgili.
bir sorgu yazdığınızda bu compenentler tarafından nasıl değerlendirilir,
bir queryin fetchi başlayana kadar compenentle FB server neler konuşur bilmek gerekiyor. bunun için de, dediğim gibi bir SQL monitor ya da
client hook programıyla işlemleri röntgenleyin. çok ilginç şeyler öğreneceksiniz. mutfağa girerseniz yemeklere daha farklı bir gözle bakarsınız...

[Terminator]

yine söylemeyi unuttum, bazı durumlarda UPLOAD hızınız önem kazanır.
internet bağlantılarının çoğu, full duplex bile çalışsa, 1/4 gibi bir upload/download hızlarına sahiptir. fiziksel olarak, download ile upload bağımsız bile çalışsa full duplex iletişimde, sonuçta yaptığınız işte, süreç olarak uploadlar downloadlar mantıksal olarak birbirini beklemek zorunda.

[sadettinpolat]

tcptrace ile portu dinlediğim vakit arada çok fazla bilginin gitmediğini gördüm.

Kod: Tümünü seç

               (E:\data\data.fdb      SADETTINsado                     
                      (E:\data\data.fdb   sysdba
QP3LMZ/MJh.:    >      (           >                    >       D            Dinsert into gruplar   (grupadi,grupaciklama,sirano) values (?,?,?)
    	

       F                   F           	

  $   ?                     ÿL         12d\    12eb        ÿÿÿÿ   2   

ibdatabase1.open
ibquery1.execsql

komutlarının sonucunda terminalden servera giden bilgiler

Kod: Tümünü seç

      
         	                              	               >                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          	                             	                             	                      = ô    ,ÿ³   T…Ø              	                                	             $     	    
 À   7  
                 	    
 Á   7  
      2           	    
 õ       
                                                                                                                                                                                                                                                                                                                                                                                                                                          	                             	                           

bunlarda serverdan terminale gelen bilgiler.

toplasan yarım kb etmez ama hız felaket yavaş.

Firebird-Architect grubunu karıştırdığımda Firebird Remote Protocol başlıklı bir mesajlaşma zinciri olduğunu gördüm. başka birileri de benim gibi bu durumdan biraz şikayetçi olmuşlar. gerçi net olarak çözüm ne önermişler anlamadım ama birisinin gruba göndermiş olduğu bir istatistik oldukça ilginç.

buraya gönderiyorum.

The server is FB1.5 and isql. Executing a simple query.

Client --> Server (20 bytes) # 29 (op_transaction)
Server --> Client (32 bytes) # 9 (op_response)
Client --> Server (8 bytes) # 62 (op_allocate_statement)
Server --> Client (32 bytes) # 9 (op_response)
Client --> Server (76 bytes) # 68 (op_prepare_statement)
Server --> Client (3504 bytes) # 9 (op_response)
Client --> Server (24 bytes) # 70 (op_info_sql)
Server --> Client (48 bytes) # 9 (op_response)
Client --> Server (20 bytes) # 69 (op_set_cursor)
Server --> Client (32 bytes) # 9 (op_response)
Client --> Server (24 bytes) # 63 (op_execute)
Server --> Client (32 bytes) # 9 (op_response)
Client --> Server (32 bytes) # 65 (op_fetch)
Server --> Client (32 bytes) # 66 (op_fetch_response)
Client --> Server (12 bytes) # 67 (op_free_statement)
Server --> Client (32 bytes) # 9 (op_response)
Client --> Server (8 bytes) # 30 (op_commit)
Server --> Client (32 bytes) # 9 (op_response)



> TCPDUMP ANALYSIS OF PostgreSQL QUERY RUN:
> -----------------------------------------
>
> query = "select count(*),'RESULT IS HERE' from test"
>
> Start
> client -> PostgreSQL, 45 bytes with the query text
> + 045 ms
> PostgreSQL -> client, 79 bytes with the result and the column headers
>
> The total query time is 45 ms.
>
>
>
> TCPDUMP ANALYSIS OF MySQL QUERY RUN:
> ------------------------------------
>
> query = "select count(*),'RESULT IS HERE' from test"
>
> Start
> client -> MySQL, 49 bytes with the query text
> + 058 ms
> MySQL -> client, 94 bytes with the result and the column headers
>
> The total query time is 58 ms.
>
>
>
> TCPDUMP ANALYSIS OF INTERBASE QUERY RUN:
> ----------------------------------------
>
> query = "select count(*), 'RESULT' from test"
>
> Start
> client -> IB, 12 bytes
> + 065 ms
> IB -> client, 32 bytes
> + 000 ms
> client -> IB, 8 bytes
> + 050 ms
> IB -> client, 32 bytes
> + 000 ms
> client -> IB, 80 bytes with the query text
> + 059 ms
> IB -> client, 64 bytes
> + 000 ms
> client -> IB, 24 bytes
> + 049 ms
> IB -> client, 40 bytes
> + 000 ms
> client -> IB, 32 bytes
> + 083 ms
> IB -> client, 236 bytes, most of it is zero and there is a text
> "COUNT" twice
> + 000 ms
> client -> IB, 32 bytes
> + 110 ms
> IB -> client, 408 bytes, most of it is zero and there is a text
> "COUNT" twice
> + 000 ms
> client -> IB, 24 bytes
> + 048 ms
> IB -> client, 32 bytes
> + 000 ms
> client -> IB, 28 bytes
> + 058 ms
> IB -> client, 32 bytes
> + 000 ms
> client -> IB, 40 bytes
> + 084 ms
> IB -> client, 40 bytes with the text "RESULT"
>
> The total query time is 606 ms.
>

server la terminal arasında gidegele bi hal oluyo.

[Terminator]

ISQL burada fazladan işlemler yapıyor olabilir kullanıcıya prepare, run sürelerini verebilmek, planı dökebilmek için. yani seni kullanacağın kompenent farklı çalışabilir.
FIBPlus kullanmayı denedin mi hiç?

FB nin Client-server ileşim protokolünün çok optimistik olmadığını biliyorum ama bu kadar da çok işlem yapmaması lazım normal şartlarda.
bu kadar çok ileşim olsa bizim 150-200 connection + normal işlemler 100 mhzlik networkü ve uygulamaları felç ederdi.

[ozkanagiral]

FB yi web sitelerimde kullanmayı düşünmüştüm özellikle sipariş sistemi olan web sitesi yaptığım müşterilerime siparişleri formmail ile göndermek yerine delphide yazdığım uygulama üzerinden, işleme ve yönetim konusunda. Sanırım biraz daha düşünmeliyim bu konuyu

[sadettinpolat]

FIBPlus kullanmayı denedin mi hiç?

parametre kullanmak sureyi yarı yarıya azaltıyor.

mesela

Kod: Tümünü seç

ibQuery1.Close
ibQuery1.Sql.Clear
ibQuery1.Sql.Add('Select Ad From Kisiler Where ID=' + strID)
ibQuery1.Open

her seferinde bu şekilde çalışan bir kod yaklaşık 30 saniye sürüyor sonuçları geri döndürmesi. her sefernde 30 saniye.

ama şu şekilde olursa

Kod: Tümünü seç

//ibQuery1.Close
//ibQuery1.Sql.Clear
//ibQuery1.Sql.Add('Select Ad From Kisiler Where ID=:prmID')
//buralar ayrı bir yerde set edilir.

ibQuery1.Paramers[0].AsString := strID
ibQuery1.Open

ilk sorgu 30 saniye diğerleri 15 saniye. Diğerinden farklı olarak burda yapmadığı şey Prepare işlemi. Prepare işlemi ilk çalıştırıldığında yapılıyor daha sonra sql text'i değişmediği için diğer çağrılar için ilk baştaki bilgiler geçerli olduğundan 15 saniyelik bir zaman dilimini kazanmış oluyoruz.

şu ana kadar hep ibx kullandım. bu işi bir de fibplus veya diğer bileşenlerle denemekte fayda var ama şimdilik parametre kullanmak geçici bir çözüm gibi duruyor.

[Terminator]

önerebileceğim şuan aklıma gelen bazı şeyler:

-Evet sürekli sorgu analizi yapmaması için parametrik query kullan ki
componentler daha az işlem yapsın.
-(E:\data\data.fdb şeklinde bir connection stringi gördüm iletişim paketinde. bunun yerine IP:alias şeklinde kullanman hız kazandırır.
çünkü hem string kısa olur hem de DNS le vakit kaybedilmez.
yani 127.0.0.1:VT gibi.
server FB rootunda da alias.conf dosyasına VT=E:\data\data.fdb yazarsın.
-IBX FB ile tam uyumlu değil, FB ye duyarlı FIBplus,zeoslib ya da IBOjects kullanmanı tavsiye ederim. zeoslib open source.
-FB versiyonunla client librarylerin mutalaka aynı olsun.
yani FB install paketinden çıkan fbclient.dll leri mutlaka termianllere yükle ve eski GDB32.dll kullanmalarına izin verme.
-Tablo,kolon vs isimlerinin kısa olmasının iletişimi hızlandıracağı ortada.
-GPRS vs le kullandığın terminaller için Stored procedure kullanımına ağırlık vererek iletişim ihtiyacını azaltabilirsin.

[Terminator]

+ commint yerine commitretaining kullanman transaction kapatıp açma gibi işlemleri azaltacağı için ayrıca hız kazanırsın.

[kadirkurtoglu]

s.a.

@Terminator demişki!

-IBX FB ile tam uyumlu değil, FB ye duyarlı FIBplus,zeoslib ya da IBOjects kullanmanı tavsiye ederim. zeoslib open source.

tam bu noktada kafamı kurcalayan soru; Firebird Interbase kodları üzerinden geliştirildi ancak Interbase üzerine inşa edilmedi sıfırdan yazıldı. ve Hatta 1.0 ile 1.5 arasında kod farkı vardır deniliyordu. Bu noktada IBX Interbase için geliştirilen bir bileşen seti. Sıfırdan yazıldığı söylenilen Firebird için tam uyumlu nasıl olabilir, ben bu konuda FIBPlus ile ilgili denemeler yaptım ve foruma FIBPlus ismiyle bir topic açtım. Bu topic fazla ilgi görmedi çünkü FIBPlus pahalı bir bileşen setiydi ve arkadaşlar bu açıdan baktığında pek düşünülemezdi. Bu olay ne kadar doğrudur onu bilemiyorum yani IBX FB için ideal değilse vt hususunda para vermektense IBX kullanmak düşünülebilirmi? herşeye rağmen kullanılabilrmi?

İlgili Topic
viewtopic.php?t=11037&highlight=fibplus

[Terminator]

IBXi şimdiki versiyonlarla kullanırsın ama eski versiyonlara takılı kalırsın unutma.
ne IBXin yeni çıkacak versiyonlarına geçebilirsin ne de FBün yeni versiyonlarına.
şimdilik büyük oranda uyumlu, çünkü API uyumluluğu büyük oranda devam ediyor, eskiden derlenmiş uygulamaların da çalışabilmesi için.
Ama yeni versiyonlarda IBXe borlandın IB yenilikleri eklenecek bu FB ile
uyuşmayacak, FB de değişiklikler olacak ama IBXe bu eklenmeyecek.
FB 1.5.x ve IBX 7.x e saplanır kalırsın.
bir komponente 3-5 kuruş vermemek için değer mi bilemiyorum.
eğer üretimin gelr getirici değilse o zaman zeoslib kullan, o da ücretsiz. ücretliler kadar mükemmel olması beklenemez ama.. yine de gayet iyi bir ürün.
FB de open source ama diyenlere de, FB open source doğmadı, neredeyse 20 li yaşlarda open source oldu ve pişman olunup geri alındı demek gerekiyor. Yani Interbase bir open source ürün değil.

[rsimsek]

..
Ama yeni versiyonlarda IBXe borlandın IB yenilikleri eklenecek bu FB ile
uyuşmayacak, FB de değişiklikler olacak ama IBXe bu eklenmeyecek.
FB 1.5.x ve IBX 7.x e saplanır kalırsın.
...

IBX Borland/InterBase gurubu tarafından geliştirilen bir proje ise dediğinde haklı olabilirsin.. Yani rakip ve açık kaynak kodlu FB ye uyum pek de umurlarında olmaz

[musti]

Çok kötü bu abi.
Şimdi ben BDS 2006 aldım IBX bileşenleri Interbase7.5 için ve ben install sırasında Interbase kurdurmadım sebebi FB 2.0 kurup onda calisacagimdan. O zaman biz ne yapıcaz. FB işini bir daha gözden mi gecirelim yada ayrı bir Bileşene bir daha paramı verelim. Eğrelti bileşemlerle çalışmak dogru gelmiyor bana.
Vay Vayki ne Vay