[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Szybkosc pracy aplikacji w Progressie
Chyba wiele osób będzie miała coś do powiedzenia, ale spróbuje przedstawić kilka powodów które przychodzą mi do głowy:
1. Zapisy (tzn. create/update/delete) do bazy przez pamięć dzieloną są o wiele szybsze.
2. Odczyty są też szybsze (ma to sens przy masowym przetworzaniu) chociażby z powodu braku pośrednika, który wprowadza narzut pracy dodatkowej oraz może w danej chwili obsługiwać żądanie innego klienta.
3. W niektórych zapytaniach, moim zdaniem, występują 3 fazy obróbki zapytania
- wykorzystanie indeksu wyselekcjonowanego przy kompilacji
- wykorzystanie pasującego indeksu nie wskazanego przy kompilacji (jest to bardzo ukryta informacja) on-line (optymalizacja zapytania przez proces serwera lub "self-service" klienta)
- ew. sprawdzenie warunków na kliencie (np. wartość funkcji)
z powyższego wynika, że przynajmniej sprawdzenie warunków o wiele szybczej odbędzie się bez pośrednictwa sieci
Pozdrawiam,
Siergiej Szabłykin.
>>> jsapinski@amadeus.net 07/01 1:41 >>>
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"
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
------