aplikacje WWW

[Tomasz Kłoczko]

On Sun, 19 Jan 2003, Radoslaw Zielinski wrote:

> Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [18-01-2003 19:25]:
> > On Sat, 18 Jan 2003, Jacek Rembisz wrote:
> > [..]
> >> No dobra może być, ale mnie wciąż martwi problem innych serwerów HTTP.
> [...]
> > Jakby nie patrzeć światek httpd mocno sie powiększył od czasów pierwowzoru
> > httpd czyli ncsa-httpd na którym później był wzorowany pierwszy indianin.
> [...]
> > W tej sytuacji może być coraz mniej istotne to o czym piszesz i to tym
> > bardziej, że nie widać choćby u nas jakiegoś dużego zainteresowania choćby
> > właśnie wpsomnianym boa.
> [...]
> 
> Spokojnie z takimi wnioskami.
> 
> Na chwilę obecną, indianiec rządzi.  Ma potężne możliwości i pod tym
> względem we wszystkich chyba przypadkach się sprawdza.  Ale te możliwości
> kosztują sporo zasobów.  W przypadku serwowania zasobów statycznych,
> używanie tak odbajerowanego serwera preforkującego jest zupełnie zbędne.

Przykładowo znam całkiem niedaleko jedno miejsce gdzie pojedyncza instacja
z php zajmuje poniżej 15KB RSS (obecnie seryjny indianin przy dosć
minimalnym zbiorze modułów zajmuje ~500KB). Zdaje się że ostanio docięto
to nawet do około 5KB RSS. Reszta pamięć jaka jest potrzebna tutaj to SHM
które jest współdzielone między wszystkie instancje httpd i aplikację
zewnetrzna karmiącą to wszystko gdzie z użyciem już PHP jest organizowany
min. cache wszystkich rzeczy serwowanych. Totalnie obcięta wersja. Niestey
po mimo że udało mi się raz zerknać na te patche dzięki którym było
możliwe takie przycięcie to nie są one do wykorzystania bo nie są i nie
bdą publicznie dstępmne a i zakres ich stosowalnosci jest ściśle określony
do konkretnego miejsca (samą specyfiką przycięcia :).

Dzięki temu mógł powstać klastr kolektorów http (po php wycigąne są różne
rzeczy z kilkuset baz danych i całość po zapakowaniu w html jest
serwowana) które miały dużo mniejsze wymagania pamięciowe, a każda
maszynka jest w stanie obsługiwać po kilkanaśie tysiecy sesji jednoczęnie.
Wszystkich szczegółów nie znam ale w porywach zapewne w powywach może do
ponad 100 tyś tysięcy sesji .. w tym wypadku jest to Solek i tutaj z
odrobina wprawy daje się obsłużyć aż tyle połączeń jednoczesnie choć na
każde połącznie kernel łyka sobie po kilka KB, i już na starcie systamu
musi być od razu na zaś łykane (dzieki też zmianie konfiguracji na
poziomie kernela) alokowane naście GB pamieci tylko na obsługę połączeń na
poziomie kernela. Tylko nie pytajcie się mnie ile kosztuje ta maszyna :)
(całość jest jeszcze z pełnym HA .. np. podwójne dwuportowe kontroletry
FCA krzyżowo łączone do dwuch niezaleznych macierzy z protegowanym
storage, każda macierz pojemnści raczej rzędu TBajtów każda :-)

W tym wypadku chodziło rzeczywiście o bardzo mocne ścięcie instancji
indianina żeby było wogól możliwe obsługiwanie nawet dzisiątków czy setek
tysięcy sesji z pojedynczej maszyny.

Może aż takie ścięcie żeby nie stracić pewnych fukcjonalnści nie ma sensu
na szerszą skalę ale takie rzeczy na swoje potrzeby w mniejszym czy też
większym zakresie wykonuja całkiem sporo firm. Wszystkie tago typu rzeczy
są mozliwe dlatego, że wszyzscy mają dostęp do źródeł i o ile będzie
potrzeba wykonywania np. aż tak daleko posunietej lobotomii dopasowującej
ściśle do konkretnych zastosowań to zawsze będzie można to zrobić.
Najważniejsze w tym wszystkim jest to że w tym wycietym podzbiorze
funkcjonalności nadal jest to indianin.

W sumie w indianinie jest i tak sporo właśnie takiego wiszącego i nikomu
nie potrzebnego kodu. Robienie takiego odchudzajacego patcha publicznie
miałoby zapewne sens. Przy utraci nawet pewnych kawałków mało kto by
zauważył że tego czegoś nie ma. Kto wie może nawet miałoby sens włączenie
domyślnie na bcond takiego patcha (?) lub części akwałków takiego czegoś
(o ile każdy wyłączałby jakąś cześć rzeczy rzadko w nim używanych).

W sumie to co chciałem powidzieć przez powyższe to to, że znajomość
jednego httpd wystarczać w sumie może na dużo większa klasę zastosowań niż
Ci się to wydaje .. i tym httpd jest właśnie indianin :)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*