[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Szybkosc pracy aplikacji w Progressie



Ja wskazalbym dwa powody:

1. W starszych wersjach Progress'a do klienta przesylane bylo mnostwo danych z
serwera, to nie bylo kilka wierszy, ktore sa rezultatem zapytania SQL.
Ostateczna selekcja rekordow odbywala sie na kliencie a nie na serwerze. O ile
sie orientuje to dopiero zupelnie od niedawna jest komponent, ktory umozliwia
pelna analize zapytan SQLowych na serwerze i przeslanie samych rezultatow na
klienta.

2. Domyslna wartosc parametru -Mm, ktory okresla wielkosc paczki danych,
przesylanych od serwera do klienta, wynosi 1KB. W dzisiejszych czasach, gdy
standardem sieci lokalnych staje sie Fast Ethernet (100MB/s), dzielenie danych
na jednokilobajtowe paczki jest calkowitym anachronizmem. Przestawienie tego
parametru na wartosc maksymalna - 32KB - moze spowodowac kilkudziesieciokrotne
przyspieszenie. 

Pozdrawiam!

Tomasz Judycki

Textus Virtualis Sp. z o.o.
Szaserów 3
04-293 Warszawa
tel/fax (48 22) 879 82 00
http://www.tv.com.pl


jsapinski@amadeus.net wrote:
> 
> Witam,
> 
> mam pytanie dotyczace struktury wielowarstwowej. Juz kilkakrotnie spotkalem
> sie z opinia, ze Progress dziala o wiele wolniej (kilakakrotnie) przy
> polaczeniach przez siec niz przez pamiec wspoldzielona i to nawet w
> przypadku b. szybkich sieci lokalnych). Czy jest to prawda? A jesli tak to
> dlaczego tak sie dzieje? Przeciez ilosc informacji wymienianej pomiedzy
> klientem a serwerem jest stosunkowo niewielka : zapytanie SQL i odpowiedz
> (kilka wierszy w systemach OLTP)
> Moje dotychczasowe doswiadczenia (Informix, Oracle) wskazywaly na to, ze
> komunikacja przez TCP/IP wnosila tylko niewielkie opoznienie i czas
> odpowiedzi wzrastal nieznacznie (max. 10% w przypadku szybkiej sieci
> lokalnej).
> 
> Pozdrawiam,
> 
> Jacek Sapinski
> 
> From:  grzegorz.jandura@valeo.com@zeto.bydgoszcz.pl  on 01/07/2002 12:56
>        ZE2
> 
> Please respond to progress@zeto.bydgoszcz.pl
> 
> Sent by:    owner-progress@zeto.bydgoszcz.pl
> 
> 
>  To:   progress@zeto.bydgoszcz.pl
> 
> 
>  cc:
> 
> 
> 
> 
> 
> 
>  Subje Re: Szybkosc pracy aplikacji w
>  ct:   Progressie
> 
> 
> Generalnie jest to prawda, tylko co ma zrobić ktoś, kupił software taki, a
> nie inny. W tym wypadku jeżeli dostawca nie jest w stanie szybko pomóc
> zostaje Windows 2000 Terminal Server albo Citrix.
> 
> -----------------------------------------------------------
> Grzegorz Jandura
> e-mail: grzegorz.jandura@valeo.com
> -----------------------------------------------------------
> 
>                       "Pawel Dobrzynski"
> 
>                        progress@zeto.bydgoszcz.pl
>                       m>                            cc:
> 
>                       Sent by:                      Subject: Re: Szybkosc
> pracy aplikacji w Progressie
>                       owner-progress@zeto.b
> 
>                       ydgoszcz.pl
> 
>                            2002-07-01 09:43
> 
>                           Please respond to
> 
>                                    progress
> 
> Zastosowanie Citrixa może być pomóc, choć jest to rozwiązanie drogie i
> wymagające dużych zasobów na serwerze. Najbardziej eleganckie i
> przyszłościowe jest przeniesienie aplikacji do architektury n-warstwowej.
> NAwet jeżeli fizyczna konfiguracja będzie dwuwarstwowa (klient - serwer),
> możliwe będzie uruchamianie częsci procedur na serwerze bazy danych, a
> części na końcówce klienta. Miejsce uruchomienia procedury można zmianiać,
> znajdując optymalne rozłożenie przetwarzania pomiędzy klienta i serwera
> przy jednoczesnym ograniczeniu ruch sieciowego. W tym przypadku serwer
> aplikacji pracuje na jednej maszynie razem z serwerem bazy danych, co może
> powodować konieczność zwiększenia zasobów serwera (w porównaniu do czystej
> architektury klient-serwer), jednak zapotrzebowanie na zasoby powinno być
> mniejsze niż przy zastosowaniu Citrixa, gdyż duża część przetwarzania może
> być rozproszona na stacje klienta, dysponujące przecież w sumie bardzo dużą
> mocą obliczeniową, która w przypadku Citrixa będzie wykorzystywana w
> niewielkim stopniu.
> 
> Architektura n-warstowa otwiera przed aplikacją nowe perspektywy:
> - możliwość łatwego dołączenia interfejsu internetowego do wybranych
> funkcji (B2C)
> - możliwość elastycznego uruchamiania w sieciach lokalnych lub w intranecie
> - łątwość zastsowania dowolnego interfejsu (znakowy, graficzny, http,
> java)+-
> - możliwość centralizacji bazy danych i oporgramowania, bardzo istotna w
> firmach wielooddziałowych gdzie pozwala ograniczyć koszty administrowania
> aplikacją, ułatwia wdrażanie nowych wersji i dodawanie nowych stanowisk
> - możliwość łatwego zintegrowania z innymi aplikacjami firmy i wymiany
> danych on-line z aplikacjami partnerów.
> 
> Przejście do architektury n-warstwowej wiąże się z pewnymi nakładami pracy,
> jednak są one mniejsze niż napisanie aplikacji od nowa, gdyż wiele
> fragmentów kodu można ponownie wykorzystać.
> 
> Paweł Dobrzyński
> 
> Leszek Drabik wrote:
> >
> > Witam ..
> > Czy ktos moze ma jakies doswiadczenie z przyspieszeniem pracy aplikacji
> > klient-server.
> > Aplikacje pracuje w sieci rozleglej ktora niestety nie jest zbyt
> > szybka.. Odbija sie to na szybkosci pracy aplikacji.
> > Server bazy (Progress 9.1C) pracuje na SUNie (wersja SunOS 5.6)..
> > Natomiast na koncowkach sa klienci Progressa (rowniez 9.1C) pod
> > Windowsami (Windows98 lub Win2000).
> > Czy rozwiazaniem w tej systuacji jest przejscie na prace terminalowa
> > (np. poprzez terminale Cytrix)?
> > Czy ktos moze ma jakies doswiadczenie z Progressem w powišzaniu z
> Cytrix'em?
> >
> > --
> > ******************************
> > *       Leszek Drabik        *
> > *       lech@megapolis.pl    *
> > *       lech75@go2.pl        *
> > ******************************
> >
> > ------
> > Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
> > Obsluga listy:  listserv@zeto.bydgoszcz.pl
> > Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
> > ------
> 
> --
> Pawel Dobrzynski <mailto:pd@progress.com>
> 
> Progress Software Polska
> http://www.progress.com/pl
> tel: (+48 22) 673-10-44
> fax: (+48 22) 610 94 83
> ------
> Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
> Obsluga listy:  listserv@zeto.bydgoszcz.pl
> Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
> ------
> 
> "This e-mail message is intended only for the use of the named
> recipient(s).
> The information contained therein may be confidential or privileged, and
> its
> disclosure or reproduction is strictly prohibited. If you are not the named
> recipient, please return it immediately to its sender at the above address
> and destroy it."
> 
> ------
> Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
> Obsluga listy:  listserv@zeto.bydgoszcz.pl
> Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
> ------
> 
> ------
> Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
> Obsluga listy:  listserv@zeto.bydgoszcz.pl
> Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
> ------

--

------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------