Odp: Re: Jak to jest z client server?

["Siergiej Szablykin" <SSzablykin@lukas.com.pl>]

   Mieliśmy w jakimś stopniu podobną sytuajce z tabelą wyników raportów, które to są zapisywane do bazy (średnia wielkość rekordu jest ok 3KB). Mamy 2 następujące środowiska :

 1. Compaq Proliant 5500 (bazy, aplikacje i inne rzeczy)
- 4x500 MHz Xeon Pentium II
- 1152 MB RAM (więcej niż zapotrzebowanie)
- zmirorowane dyski 18GB 10k rpm
- 4 kanalowy sterownik macierzowy z 56 MB RAM (naprawda szybki)
- 100 Mb karta sieciowa (full duplex itd.)
- Windows NT 4.0 SP 6a Server Enterprise Edition
- Progress 8.3a (weim że jest to staroć, w październiku przechodzimy na 8.3D - ale jest to nie istotne)
- logi systemowe i sprawdzanie uprawnień
- PDC (Primary Domain Controller)

 2. Dell PowerEdge 6400 (wyłacznie bazy i programy do raportów batch'owych)
- 4x700 MHz Xeon Pentium III
- 2048 MB RAM
- zmirorowane dyski 18GB 15K rpm (szybsze od dysków w starym serwerze)
- 4 kanalowy sterownik macieżowy z 128 MB RAM (bardzo szybki)
- 100 Mb karta sieciowa (full duplex itd.)
- Windows NT 4.0 SP 6a Server (edycja do 8 procesorów)
- Progress 8.3a
- logi systemowe i sprawdzanie uprawnień (identyczne jak na starym serwerze)
- BDC (Backup Domain Controller)

  Po wprowadzeniu kolejnych zmian do polis bezpieczeństwa nowszy serwer z 'normalnym' Windows'em zaczął zachowywać się trochę dziwnie. Rekordy z tabeli wyników raportów były selekcjonowane ok. 90 razy wolniej niż przed tym (resztę tabel ta plaga nie dotknęła). Lokalna selekcja jest wciąż szybsza niż na starym serwerze o około 10%. Po zmianie wielkości parametru -Mm z domyślniego 1K na 8K przędkość selekcji wzrosła jakieś 70 do 80 razy. Wielkość bazy w tym przypadku nie ma żadnego znaczenia: mamy na nowym serwerze 2 bazy - 30GB oraz 1GB.
  Wygłąda mi na to, że Windows w wersji nie bądącej Enterprise uwierzytelnia poszczególne bramki nie grupując je w pakiety i robi to bardzo długo. (Na czasy nie wpływa to, czy podstawową domeną logowania jest domena starego serwera czy jakaś inna domena lub grupa robocza). Może to wynikać z konstrukcji kodów wewnętrznych PSC oraz Microsoft.


Z poważaniem,
Siergiej Szabłykin.


>>> tjudycki@tv.com.pl 01-09-26 11:36 >>>
Henryk Jusza wrote:
> 
> >Wariant A.: ok. 20 sekund
> >Wariant B.: ok. 30 minut
> 
> [ciach] Oczywiście miejsce selekcji zapisów wpływa zasadniczo
> na czas transmisji. W przypadku selekcji po stronie klienta wymaga to
> przesłania dużej ilości zapisów przez sieć. Mój intuicyjny i poparty
> obserwacjami poglšd na tę sprawę jest następujšcy:
> [ciach]

Takie też są moje intuicje.

> Bardzo częstš przyczynš długiego czasu realizacji zapytań jest ich zła
> konstrukcja wymagajšca przeszukiwania całej tablicy - zapis po
> zapisie.

Generalnie to prawda, ale ja NAPRAWDĘ wykonywałem takiego for each'a, jak to
napisałem w moim liście:
> >   for each customer no-lock where cust-num < 3000000000 :
> >   end.
Inna jest nazwa tablicy i atrybutu, natomiast składnia jest identyczna, a
atrybut, na który jest warunek, jest jedynym składnikiem indeksu, który jest
primary, unique i active.

> W przypadku realizacji takich zapytań lokalnie, gdzie
> komunikacja między klientem a serwerem odbywa się przez pamięć
> dzielonš, [ciach]

No ale ja w obu wariantach podłączam się przez TCP/IP.

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 

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