Úvod
Pro tentokrát začnu nevýhodami. Thttpd je momentálně nevyvíjený, a to již poměrně dlouhou dobu (poslední verze vyšla koncem roku 2003). Mailing list projektu je sice ještě stále aktivní, ale netroufnu si odpovědět na otázku, zdali vývoj tohoto projektu bude ještě někdy pokračovat. Lze však předpokládat, že případné fatální či bezpečnostní problémy budou řešeny jako doposud, tedy na úrovni správců balíčků v distribucích, které thttpd obsahují. Mezi další nevýhody thttpd patří také absence podpory IPv6, HTTPS a FastCGI (podporuje pouze CGI).
Jeho výhody naopak zahrnují paměťovou nenáročnost (sám zabírá pod 1 MB RAM, při zátěži spotřebovává minimum paměti navíc), rychlost (u statických stránek stíhá víc a rychleji než Apache) a vestavěná podpora pro škrcení síťového provozu (throttling).
Jak už bylo zmíněno, thttpd se hodí především tam, kde je citelný nedostatek paměti a kde nevadí absence pokročilejších funkcí typických pro servery typu Apache. Bude vynikat zejména tam, kde je potřeba servírovat statické stránky. Pokud máte produkční server, popřípadě chcete dynamické stránky, budete spíše uvažovat o lighttpd či Nginx.
Instalace
Je velká pravděpodobnost, že thttpd máte v repozitářích své distribuce, takže by mělo stačit nainstalovat stejnojmenný balíček. V Debianu byste instalaci thttpd provedli takto:
aptitude install thttpd
Základní konfigurace
Primární konfigurační soubor pro thttpd je /etc/thttpd/thttpd.conf. Výchozí nastavení je v Debianu postačující pro provoz na portu 80, přičemž obsah, který thttpd servíruje, má výchozí umístění shodné s Apache, tedy /var/www. Pokud vám toto nastavení vyhovuje, můžete přejít rovnou ke spuštění serveru. V opačném případě můžete tyto hodnoty upravit, třeba takto:
port=8000 dir=/srv/http
Thttpd se na rozdíl od jiných webových serverů v Debianu po instalaci automaticky nespustí, jeho použití je potřeba nejprve povolit v /etc/default/thttpd, kde musíte volbu ENABLED nastavit na yes:
ENABLED=yes
Teprve poté nastartujte thttpd:
/etc/init.d/thttpd start
chroot a bezpečnost
Z bezpečnostních důvodů je doporučeno používat chroot, tj. uzavřít běh serveru v adresáři s obsahem, který má thttpd servírovat. Tak je také thttpd v Debianu ve výchozím stavu nastaven. Pokud vám toto nastavení nevyhovuje, zaměňte volbu chroot za nochroot.
Podobně jako Apache nebo jiné webové servery i thttpd po spuštění změní uživatele z roota na neprivilegovaného uživatele, v Debianu je to uživatel www-data (toto upravuje volba user).
Nastavení throttlingu
Pro domácí servery má thttpd jednu velkou výhodu - má vestavěný throttling, tedy „škrcení“ síťového provozu, což se velmi hodí tam, kde máte škrcený upload (mj. prakticky veškeré domácí ADSL). Throttling se nastavuje ve zvláštním konfiguračním souboru, a sice v /etc/thttpd/throttling.conf. Samotné nastavení může vypadat třeba takto:
** 5000-10000 **.jpg|**.png 5000 files/** 5000
První řádka udává globální nastavení pro všechny soubory, přičemž maximum je stanovené na 10000 bytů za vteřinu. První číslo, tedy 5000, udává minimum. Druhý řádek dává všem jpg a png souborům maximum 5000 bytů za sekundu. Poslední řádka naznačuje, jak by se postupovalo pro všechny soubory v určitém adresáři, v tomto případě se jedná o adresář files, kterému je rovněž nastaveno maximum přenosů na 5000 bytů za sekundu.
Benchmark webového serveru pomocí nástroje ab
Přemýšlíte-li nad tím, jakým způsobem změřit výkon webového serveru při zátěži, můžete zkusit nástroj ab z balíčku apache2-utils. K instalaci vám v Debianu postačí následující příkaz:
aptitude install apache2-utils
Oddělení balíčků je zde velmi prospěšné, neboť nemusíte kvůli tomuto nástroji tahat celou distribuci Apache, postačí vám pouze tento balíček.
Nástroj ab má dva klíčové parametry, a sice celkový počet HTTP žádostí (-n) a počet současně posílaných žádostí (-c). Výchozí hodnotou je u obojího jednička. Pokud tedy chcete otestovat místní server zasláním dvou tisíc žádostí, přičemž současně by se posílalo třicet žádostí, vykonali byste následující příkaz:
ab -n 2000 -c 30 http://127.0.0.1/
Pro ukázku uvádím výstup tohoto příkazu právě v případě thttpd:
Server Software: thttpd/2.25b
Server Hostname: 127.0.0.1
Server Port: 80
Document Path: /
Document Length: 1399 bytes
Concurrency Level: 30
Time taken for tests: 0.135 seconds
Complete requests: 2000
Failed requests: 0
Write errors: 0
Total transferred: 3272000 bytes
HTML transferred: 2798000 bytes
Requests per second: 14760.58 [#/sec] (mean)
Time per request: 2.032 [ms] (mean)
Time per request: 0.068 [ms] (mean, across all concurrent requests)
Transfer rate: 23582.34 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 2
Processing: 0 2 0.5 2 3
Waiting: 0 1 0.6 1 3
Total: 0 2 0.6 2 4
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 3
90% 3
95% 3
98% 3
99% 3
100% 4 (longest request)Ve výpisu jsou patrné podstatné statistické údaje, tedy nejdelší požadavek, během jaké doby byla obsloužena většina požadavků, přenosová rychlost, počet přenesených bytů apod. Pokud to s bechmarkováním budete myslet vážně, určitě se podívejte do manuálové stránky nástroje kvůli ostatním volbám.
Pár slov o benchmarkování
Aby měl jakýkoliv benchmark smysl, je potřeba zadat správné parametry a výsledky správně interpretovat. Už samotná volba testovací stránky skýtá mnoho úskalí. Pokud testujete na statické stránce, ale hodláte nasadit dynamické stránky (resp. webovou aplikaci), nemusí mít test vůbec žádnou vypovídací schopnost. Podobně, testujete-li jednu konkrétní dynamickou stránku, je třeba mít na paměti, že u jiných stránek může být výkon řádově jiný (provádí se jiné SQL dotazy, jiné zpracování dat apod.). Jinými slovy, před započetím testování byste měli mít jasnou představu, co chcete testovat, a měli byste si být jisti, že jste zvolili správnou metodu, jak to otestovat. Určitě nebývá od věci kromě výsledků sledovat i zatížení systému, obsazení paměti a další parametry během samotného benchmarku.
V příkladu výše vás mělo zarazit to, že test byl prováděn z localhostu, tj. přímo na serveru. Takový test může být vhodný, pokud testujete „surový“ výkon webového serveru, kde by mohla síťová vrstva výsledek ovlivnit. Naopak pro testování z pohledu uživatelů webu není dobré síť ignorovat, jelikož její režie si vždy něco vezme. V souvislosti s tím byste si také měli dávat pozor, odkud server testujete, aby vám nízký upload vašeho ISP nezkreslil výsledky.