[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Szybkosc pracy aplikacji w Progressie
Baza danych PROGRESS od wersji 9-tej
została wyposażona w "SQL-92 database engine".
Pisząc programy w jęz. JAVA, które za
pośrednictwem
driver-a JDBC wykonują polecenia SELECT nie
zauważyłem
różnicy w szybkości wykonywania tych poleceń w
stosunku
do polecenia 4GL: FOR EACH...., obsługiwanego
przez motor bazy danych dedykowany klientowi 4GL.
Nie mam doświadczeń związanych z wydajnością tego
typu poleceń operujących na innych bazach danych,
lecz nie spodziewam się tutaj dużych różnic
(relacyjne bazy danych to produkty rozwijane
przez czołowych dostawców przez kilka ładnych
lat i poziom technologii w zakresie podstawowych
usług - np. optymalizacja zapytania SELECT - chyba
zdążył się wyrównać ?).
Brak pośrednictwa sieci pomiędzy serwerem
bazy danych a klientem wpływa natomiast znacząco
na szybkość przetwarzania danych. W pewnych
przypadkach
można zwiększyć wydajność systemu, o ile
przetwarzanie
danych odbywa się na tej samej maszynie, na której
pracuje serwer bazy danych . Jest to łatwo
zauważalne
przy modyfikacji dużej liczby rekordów. Lepszym
rozwiązaniem jest zastosowanie procedur
składowanych
(stored procedures), które są wykonywane przez
serwer bazy
danych, a co za tym idzie nie generują ruchu w
sieci.
Na razie jest to rozwiązanie dostępne tylko
poprzez JDBC lub ODBC, lecz być może w przyszłości
PROGRESS udostępni je również klientom 4GL...
Pozdrawiam
-
Bogdan Brzozowski
Kier. Działu Oprogramowania
Z.U.I. NOVUM Sp. z o.o.
Spokojna 9A
18-400 Łomża
POLAND
e-mail: bogdan@novum.pl
> -----Original Message-----
> From: owner-progress@zeto.bydgoszcz.pl
> [mailto:owner-progress@zeto.bydgoszcz.pl
> ]On Behalf Of
> jsapinski@amadeus.net
> Sent: Monday, July 01, 2002 1:41 PM
> To: progress@zeto.bydgoszcz.pl
> Subject: Re: Szybkosc pracy aplikacji w
> Progressie
>
>
>
> 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.bydgoszc
> z.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
------