[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
------