Jaki jest Twoj ulubiony serwer WWW?

[TQM]

Hej!

Wlasnie zastanawiam sie nad przesiadka na inny serwer WWW. Na razie nie mowie dlaczego i po co ani z czego na co ale do tego sadze dojdziemy dalej. Na razie chcialbym poznac Wasze zdanie - jaki software najbardziej lubicie jako serwer WWW?

Nie pytam z jakiego korzystacie i robie to celowo, poniewaz wiem, ze niektorzy sa zmuszeni pracowac na czyms innym niz ich prywatny ulubieniec bo decyzje podejmuje firma, itd.

Interesuje mnie szczegolnie co lubicie/nie lubicie w serwerach WWW. Ankieta jest skierowana do osob, ktore konfiguruja/konfigurowaly serwery WWW czy to dla swojego pracodawcy czy tez na wlasny uzytek na domowym komputerze.

[gogulas]

Hmm, czy mi sie wydaje, czy caly swiat jedzie na Apachu? ;p

[eMCe]

Apache - Dlaczego?
1) obszerna dokumentacja - jest popularny - dużo osób go zna - wiec w razie jakiś problemów będzie się kogo poradzić...

właściwie nie testowałem innych - wiec nie mogę podawać innych powodów - typu łatwy w obsłudze... - bo któryś z innych może być łatwiejszy - porostu już się chyba przyzwyczaiłem - i dobrze mi z nim - działa i u mnie w domu i w firmie na serwerku - i nic sie nie dzieje - śmiga szybko - jest ok - to tyle

[Nikow]

Dlaczego nie można zaznaczyć dwóch?
Ja tam jadę na apache i na pythonowym...

[TQM]

Hehe - zaznacz ten 'bardziej ulubiony'
Zanim ruszymy dalej poczekajmy jeszcze moze ktos cos jeszcze dorzuci - ankieta zaczela sie wczoraj wieczorem, wiec dajmy szanse innym.

[TQM]

Dobra - chyba moge juz napisac o co mi chodzi i dlaczego zaczalem ten watek... watpie abysmy zebrali wiecej glosow w ankiecie.

Zacznijmy od faworyta obslugujacego aktualnie ponad polowe witryn na swiecie - Apache

Spora kobyla az tlusta od funkcjonalnosci jakie oferuja moduly itd. Niestety ma swoje ograniczenia. Na niektore bardzo bolesnie natknalem sie niedawno.

1. Apache 1.3.x i 2.x dzialajacy z mpm-prefork (emulacja zachowania 1.3.x) normalnie radzi sobie do 100 rownoczesnych polaczen - niby spoko ale... na jednym z moich serwerow robimy po 30-40 transakcji na sekunde (w sensie wykonania kodu aplikacji) i nie ma problemow ale drugi serwer padl przy lekkim ruchu - wyczerpalismy 100 polaczen i to na 1 tylko domenie... po prostu ludzie albo mieli powolne lacza albo juz sam nie wiem co... porazka! Oczywiscie ten limit mozna podniesc ale to wymaga znowu wiecej RAMu.
2. Apache 2.x z mpm-worker ktory uzywa thread'ow nie jest do konca bezpieczny - php nie jest thread-safe, mozna miec rozne ciekawe objawy... rozwiazanie to uzywac PHP jako CGI np przy wykorzystaniu FastCGI - nie moge narzekac - ladnie dziala...
3. O tym nawet nei wiedzialem... ale moja sympatia dla apacza nieco opadla http://people.apache.org/~rbowen/pre...ate_apache.pdf

Teraz czas na zalety:

1. Latwy w konfiguracji (jak juz sie go opanuje)
2. Banalna obsluga znacznych ilosci domen - kazda domena ze swoimi udziwnieniami (u mnie nie ma tak prosto)
3. Wypasiony mod_rewrite - dosc czesto go uzywam wiec to dosc istotne... regulki czesto maja po kilka(nascie) linijek
4. Ogromny wybor modulow - pozwol innym wykonac Twoja prace
5. ... chyba kazdy moze tu jeszcze sporo dopisac...

pomimo bardzo liczych zalet, ogromnej popularnosci itd skupie sie jednak na wadach (poniewaz jak napsialem zastanawiams ie nad zmiana serwera).

Apache 1.3.x/2.x + mpm-prefork - pamieciozernosc jest ogromna! W obu przypadkach dla kazdego polaczenia odpalany jest osobny proces potomny serwera. Niech teraz serwer ma wlaczone mod_php, mod_rewrite, kilka dodatkow ktore sa mniej istotne... rozmiar procesu w pamieci to 10.5 i wiecej MB. Ja przekraczam 20MB leciutko, do tego dochodzi jeszcze iles workerow aplikacyjnych ktore sami tworzymy. 2GB RAM to za malo aby pomiescic w 100 procesow a co to jest 100 polaczen? To jest NIC!

Apache 2.x + mpm-worker - model wielowatkowy, 1 proces serwera ma np 25 watkow ktore sluchaja polaczen - dopuki reguest nei przejdzie w calosci worker nic nie robi, po prostu czeka az watki dadza znac ze maja dla niego robote (kolejkowanie zamowien) i wtedy zabiera sie za robote. Jest to o wiele bardziej optymalne, ale wiekszosc aplikacji nie jest przygotowana do pracy w srodowisku wielowatkowym. Jesli idzie o PHP to co kawalek sa infomacje, ze mozna sie niezle przejechac ale na to sa sposoby ktore dzialaja, wiec to nie jest wielki problem.

Praktyczne znaczenie uzycia thread'ow? Wezmy np. delikwenta ktory robi 'telnet serwer 80', serwer go podlacza i czeka na polecenie... ale user nic nie wpisuje... Domyslnie apache ma timeout ustawiony na 5 minut. W takim wypadku proces serwera jest zajety przez 5 minut nic nie robiac ale nie akceptujac zadnych nowych polaczen! W przypadku modelu watkowego to nie jest problem - odpalamy niech bedzie 25 workerow, kazdy po 25 watkow i mozemy zakolejkowa 625 polaczen ktore beda obslugiwane gdy tylko beda wolne zasoby, czyli takie polaczenie bedzie sobie wisiec blokujac 1 thread, gdy pozostale 24 thready w jednym tylko workerze beda wolne i beda normalnie obslugiwac polaczenia.
Do tego dochodza jeszcze zabawy z Keep-Alive itd ale to juz odsylam do dokumentacji.

Ogolnie zadne z powyzszych rozwiazan mi nie pasuje tak do konca, wiec mysle o napisaniu wlasnego serwera posiadajacego cos w rodzaju thread'ow i asynchroniczne I/O ale to zobaczymy... szkielet juz jest.

Wydajny i lekki, ale... po prostu lighttpd

To moja nowa zabawka, staram sie dokladnie testowac co potrafi. Powiem wprost - mysle o przesiadce na ten wlasnie serwer - nie wszedzie oczywiscie dam rade ale powolutku chce rozpoczac migracje.

Zalety:

1. powstal jako PoC dla problemu c10k (google: c10k) po czym byl za dobry aby go wyciac, wiec zostal :P
2. 1 dzialajacy proces serwera i zadziwiajaco wysoka wydajnosc
3. doskonale czasy odpowiedzi dla skryptow PHP (PHP jako CGI a nie FastCGI wiec mozna jeszcze poprawic) oraz CGI pisanych w Perlu
4. prosta konfiguracja - ssl, fastcgi, ograniczanie przepustowosci klientom, zbieranie danych dla rrd, redirecty, virtualne domeny (banalna konfiguracja przy uzyciu mod_simple_vhost) oraz wiele innych
5. Maly footprint w pamieci - dzialajacy serwer to TYLKO okolo 4MB

Wady:

1. obawiam sie ze nie wszystko bede w stanie w nim zrobic - chocby moje dosc zaawansowane regulki mod_rewrite w apache'u
2. serwer obsluguje albo HTTP albo HTTPS - wymaga 2 oddzielnych procesow i 2 plikow konfiguracyjnych aby miec oba na raz ale to akurat moze byc zaleta bo jest to czyste rozwiazanie - wpisuje jako wade bo nieco zajelo mi zanim znalazlem dlaczego nagle mam tylko https i moj monitoring sieci zaczal mnie zalewac SMSami

Jak na razie jestem pod wrazeniem - testuje lighty'ego na malym systemie i na razie jest super. Wielkie pytanie co do rewrite'a - musze ogarnac logike dokladnie zanim zdecydujemy.

To tyle z mojej strony - czy ktos ma cos co chcialby dodac? Cos jak glos w obronie Apache'a albo przeciw Apache'owi? To samo dotyczy lighttpd.

[kaspsior]

..................... ...

[gogulas]

Tqm, jestem slowem Apache zżera za duzo zasobow czyt. RAMu

[TQM]

To znaczy jestescie ZA czy PRZECIW jesli chodzi o uzycie Apache'a bo powyzsze 2 wypowiedzi jakos nic mi nie mowia

[Nikow]

A ja jestem pośrodku. Apache to dobry serwer "biurkowy", tzn. pięknie prezentuje się jak tworzymy jakąś swoją nową WWW i chcemy ją testować na localhoscie.
Ale gdy nie jest mi potrzebne PHP to wolę odpalić pythona, wpisać

from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
serv = HTTPServer(("", 3535), SimpleHTTPRequestHandler)
serv.serve_forever()

i mieć ładny serwer HTTP (świetnie się nadaje do udostępniania plików ).