Hlavní navigace

Lighttpd může ulehčit Apache serveru

Lighttpd je jednoduchý HTTP server, který může snížit celkovou zátěž Apache serveru při poskytování streamovaného obsahu nebo na databázi založené webové aplikaci. Lighttpd používá méně systémových zdrojů na jeden dotaz a může i většinu statického obsahu poskytovat rychleji než Apache. Jednou ze zajímavých výhod Lighttpd je, že může běžet ve spolupráci s Apache jako Apache proxy modul. Stručný návod k instalaci a nastavení si můžete přečíst na Linux.com.

Předchozí zprávička Následující zprávička        
Radek Podgorny aura:90

...anebo

...anebo ho muze uplne nahradit :-). Pokud nepouzivate nejake exoticke mod_xxx, vrele doporucuji...
VM
VM (neregistrovaný)
9. 2. 2006 16:55 Nový

slovosled...

celé vlákno
...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.
pakl
pakl (neregistrovaný)
9. 2. 2006 23:10 Nový

Re: slovosled...

celé vlákno
ta veta mi pripadne absolutne logicka
بطرس
بطرس (neregistrovaný)
9. 2. 2006 23:23 Nový

Re: slovosled...

celé vlákno
Neumí čésky! To by bylo na databázi založené na webové aplikaci
بطرس
بطرس (neregistrovaný)
9. 2. 2006 23:24 Nový

Re: slovosled...

celé vlákno
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
ac1db1tch <h4x0rr@prujem.cz>
ac1db1tch <h4x0rr@prujem.cz> (neregistrovaný)
9. 2. 2006 17:12 Nový

neni to takova slava

celé vlákno
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 :(
Miroslav Suchý aura:87
10. 2. 2006 8:54 Nový

Re: neni to takova slava

celé vlákno
To muzu jen potvrdit. Ja jsem dokonce nebyl schopny z lighttpd vubec zadny velky soubor. Tak jsem presel na mathopd, ktery neni tak vykony, ale je vykonejsi nez Apache a na zadny problem jsem u nej zatim nenarazil.
JeromeHeretic
JeromeHeretic (neregistrovaný)
9. 2. 2006 23:09 Nový

Re: neni to takova slava

celé vlákno
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.
Martin Kumst aura:90

JWS

celé vlákno
Nake PR musi byt. Vyvijim(asi spatne pravopis) vlastni jeremy http server. http://kumst.net/jeremy.php
uživatel si přál zůstat v anonymitě
10. 2. 2006 10:37 Nový

Re: JWS

celé vlákno
hmm, tak som si teda pozrel odkazovany "webserver":-)

- pri downloade (a po rozbaleni) je slusnym zvykom mat archiv s nazvom napr jeremy-0.6.6.tar.gz, resp jeremy-0.6.6/

- preco do distribucie zaradujes archivne suborov? (subory s ~ na konci)

- preco po rozbaleni maju napr .h subory executable prava ?

k stylu programovaniu ...

- zvol si licenciu :-)

- komentar, datove typy, fukncie pis v anglictine. cesky rozumie cca 20m ludi, anglicky si trufam povedat radovo miliarda

- .h subory sluzia na popis interface definovaneho v .c. priklad analyze.h

-----

#ifndef __JEREMY_ANALYZE__H__
# define __JEREMY_ANALYZE__H__

# include /* kde je definovane struct nastaveni a struct pripojeni */

int analyze (struct nastaveni *, struct pripojeni *);

#endif

------

k programovaniu (vytahy):

analyze.h:
- man strncmp
config->post_used = ! strncmp (pripojeni->dotaz, "POST", 4);
- "prasackej cyklus" mas narocnosti n^2 ... strlen sa rata v kazdom prechode, hoci je to konstanta

celkovo, skus si pozriet "man poll"
Martin Kumst aura:90

Re: JWS

celé vlákno
S temi hlavickovymi soubory mate bohuzel pravdu. Kdyz sem to zacinal psat, tak sem byl velice liny jeste k tomu delat makefile. Asi to bude nutne cele prepsat od zakladu...
Martin Kumst aura:90

Re: JWS

celé vlákno
btw dekuji za to ze ste se na to podival a navrhl mozna vylepseni... vzal jsem si to k srdci :)
Zasílat nově přidané příspěvky e-mailem