Názory k článku
Lighttpd může ulehčit Apache serveru

...nebo na databázi založené webové aplikaci
- ze by databaze zalozena pro webovou aplikaci? Autor chtel nejspis napsat o aplikaci zalozene na webove databazi, ale plete si poradi slov, a pekne to zamotal.

ta veta mi pripadne absolutne logicka

Neumí čésky! To by bylo na databázi založené na webové aplikaci

Neumí čésky! To by bylo na databázi založené na webové aplikaci! Bez této předložky je to třeba číst jako (na databázi založené) webové aplikaci

kolem lighttpd bylo posledni dobou dost humbuku, snazi se o krasnej event-model vse-vjednom-threadu, ma sendfile pro staticky fajly, ma skutecne vyrazne nizssi footprint a tak dale, fastcgi je taky o malinko rychlejsi nez v apache. ALE. vykonnost klesa rapidne dolu pokud je poskytovany obsah nad ramec cache, jednoduse a proste, souhrn stazitelnych souboru presahne velikost dostupne ram, nebo tu ram neco sezere atd. ja se dostal do stadia kdy to na xeonu 3.2ghz se 4GB ram jelo 1 requestu za 10 vterin na url ktere se disku ani nedotklo (napr invalid request) jenom proto ze tu bylo asi 200 simultannich downloadu velkych souboru (iso image). vysvetleni je na snade - lighttpd cte z disku (resp. blokuje na I/O, nejcasteji stat() ci sendfile()) a ostatni maj smulu. stejny problem maji thttpd, boa a dalsi single-thread servery. castecne se to da resit tim ze lighttpd ma nastaveni na pocet instanci(doslova 1:N threading) ale pri 200 bezicich procesech uz to zere 10x vic nez apache s worker mpm ve stejnych podminkach. az si nekdo da tu praci a udela do lighttpd AIO tak to teprv bude to spravny maso :). takze soucasnost je v konecnem dusledku takova ze ze apache zvladne to co lighttpd s o neco vetsim overheadem, a na velke staticke filearchivy je naprosto vyhrava. argumentace ze php a ruby jede pres fastcgi v lighttpd dobre je taky trosku postavena na hlavu, protoze oba jazyky maji 100x vetsi overhead nez cele lighttpd a apache dohromady.
a to nemluvim o problemech lighttpd s poctem childu fastcgi, protoze se mi ho proste nepodarilo donutit spawnout nove fastcgi kdyz sou vsechny soucasne busy, takze vysledek je ze bezi treba 8 requestu na preforknutych php fastcgi, kazdy saha na 1s do databaze a ostatni maj smulu. zkratka thready sou zlo ale pokud se jim chce nekdo vyhnout, musi to udelat poradne :)

pouzivat lighttpd jako mod proxy je prakticky k nicemu protoze se overhead a nevyhody lighttpd secte s apachem :(

Tedy je videt, ze jsi to zkoumal. Ja o tom slysim prvne, tak jsem do komentaru jen tak zvedave nahledl, protoze me okamzite napadla prave ta myslenka, co pises v posledni vete. Timto si mi potvrdil me podezreni, takze asi lighttpd sice hezke, ale jeste na tom Rakev pracuj a trebas to po tobe jednou pojmenujem. Do te doby si asi vystacim s Boou.