Hlavní navigace

Lighttpd: Zajímavé moduly

Adam Štrauch 12. 9. 2008

Poslední díl našeho malého seriálu o Lighttpd bych rád věnoval menším modulům, které umí život ulehčit nebo nabízejí funkcionalitu, kterou by si uživatel musel ohlídat v jiné aplikaci. Řeč bude o kompresi, cachování, monitoringu, webdavu a redirectu/rewritu.

Konfigurace generovaná skriptem

Konfigurace se vztahuje pouze na jeden soubor, ale můžeme do něj vkládat i další. Můžeme si také napsat skript, který vygeneruje konfiguraci třeba pro každý jednotlivý web a ta se pak vloží do hlavního konfiguračního souboru při spouštění web serveru.

Možná už na začátku jsem měl zmínit, že konfigurace se nedá za běhu jakkoli ovlivňovat (pokud nepočítáme např. modul mod_mysql_vhost) a i při nepatrně změně musíme web server restartovat. To je naštěstí u Lighttpd otázkou pár vteřin.

Příklady:

   # tímto řádkem do konfigurace mého lighttpd vkládám rewrite a redirect pravidla pro každý web
   # používám k tomu skript rrmods s adresářem jako parametrem
   # includuje se standardní výstup skriptu
   include_shell "/usr/local/bin/rrmods.py /etc/lighttpd/rrrules/"

   # druhou možností je vložení obsahu jednoho pevně daného souboru
   include "/etc/lighttpd/rules/rule1.conf" 

Komprese

Pro ušetření pár procent linky, na které je web server připojen, je možné zapnout kompresi odesílaného obsahu. Na první pohled se možná jedná o zbytečnou vlastnost, ale lidé, kteří používají mobilní nebo jiné „pomalé“ připojení, kompresi ocení. Ale ani ostatní kompresí nepohrdnou. Správně nastavený server může načítání stránek urychlit i na relativně rychlých linkách. Samozřejmě jsou zde kladeny větší nároky na procesor.

V každém požadavku prohlížeč odesílá na server informace o tom, že podporuje kompresi, a podle toho se server rozhodne, co pošle. Nastavení pak tkví v určení adresáře pro ukládání zkomprimovaných dat, typ dat, která se mají komprimovat a nakonec maximální velikost originálního souboru. Lighttpd aktuálně podporuje kompresi pouze statických souborů, ale u dynamického obsahu není nic ztraceno.

Většina způsobů vytváření dynamických stránek má podporu pro kompresi již rovnou v sobě. Například u PHP stačí zapnout:

   zlib.output_compression = 1
   zlib.output_handler = On 

Do nastavení Djanga přidat:

    MIDDLEWARE_CLASSES = (
    [...]
    'django.middleware.gzip.GZipMiddleware',
    [...]
   ) 

Zapnutí komprese vypadá následovně:

   compress.max-filesize = 4096
   compress.cache-dir    = "/tmp/cache"
   compress.filetype     = ("text/plain", "text/html") 

Cachování

mod_cache

Pro cachování obsahu se používá modul „mod_cache“. Je to modul třetí strany a tak není zahrnut v oficiálním repozitáři. Cachování slouží pro odlehčení linky mezi cache a web serverem, ale také například pro redukci SQL dotazů na databázový server. Tento modul je silně spojen s modulem mod_proxy a pracuje pouze s ním. Hodí se na místech, kde slouží Lighttpd jako „předvoj“ pro další web servery.

Instalace spočívá v aplikování patche, který lze nalézt v dokumentaci. Problémy mohou nastat u aktualizací, kdy nemusí být k dispozici tento modul hned po vydání nové verze.

Konfigurace je jednoduchá a víceméně spočívá v určení, která URL se mají cachovat a jak často aktualizovat. Pro vypsání seznamu zboží se už aplikace nemusí dožadovat několikrát databáze o data a použije se stránka z cache. Některé volby se liší ve verzi 1.4 a 1.5, proto v příkladu uvedu pouze 1.4, protože je momentálně stable a vyskytuje se ve většině distribucí.

   cache.bases             pole s adresáři, kde se budou ukládat cachované stránky
   cache.enable            zapnutí/vypnutí cachování
   cache.domains           pole s doménami, které budou cachovány
   cache.support-queries   zohledňování proměnných v URL
   cache.debug             zapnutí/vypnutí ladících hlášek
   cache.purge-host        seznam IP adres (i s maskou), kterým se zobrazí originální obsah
   cache.refresh-pattern   pole s URL, které budou cachovány 

Příklad jednoduchého nastavení:

   cache.bases = ("/tmp/cache") #adresář pro ukládání cachovaných dat
   cache.refresh-pattern = (
       # cachovat hlavní stránku a obnovit ji při požadavku a refresdh nebo po pěti minutách
       "/$" => "5 update-on-refresh no-expire-header",
       "\.(?i)(htm|html|shtml)$" => "30", # cachovat *htm* soubory a obnovovat je každých 30 minut
       "\.(?i)(jpg|bmp|jpeg|gif|png)$" => "2880", # cachovat obrázky a obnovovat je každé 2 dny
   )
   proxy.server  = ( "/" => (( "host" => "10.1.0.1", "port" => 80 )) ) # napojit se na web server
   proxy.worked-with-mod-cache = "enable" #zapnout podporu mod_cache v mod_proxy 

Modul mod_cache musí být načten až po modulu mod_proxy.

mod_mem_cache

Tento modul opět není zahrnut do oficiálního stromu a patche lze stáhnout z odkazů v dokumentaci. Na rozdíl od mod_cache funguje i na lokálních souborech. Druhá odlišnost je, že cachovaná data neukládá do souborů, ale do paměti. Díky tomu je servírování několika tisíc malých souborů pro lighttpd doslova hračkou.

Konfigurace není náročná, a proto je dobré aspoň pár MB pro tuto činnost obětovat. Při zobrazení stránky web server neodpovídá pouze na jeden požadavek, ale někdy i na několik desítek. Když pak nemusí lovit na disku CSS a obrázky s designem k vašemu webu při každém kliknutí uživatele, ušetří se spousta času, který by se jinak strávil čekáním na disk. Podobné problémy zažívá každá větší webová stránka.

Hodnoty:

   mem-cache.filetypes         mimetypy, které se mají cachovat
   mem-cache.enable            zapnutí/vypnutí cache
   mem-cache.max-memory        maximální celková velikost cache
   mem-cache.max-file-size     maximální velikost soubory v cache
   mem-cache.lru-remove-count  počet položek které se zahodí, pokud cache dostane k horní hranici paměti
   mem-cache.expire-time       čas po kterém data v cache expirují 

Příklad:

   mem-cache.filetypes  = ("application/x-javascript", "text/css", "text/html", "text/javascript") # cachovat javaskript, css a html soubory
   mem-cache.max-memory = 256 # K dipozici bude 256 MB pamětí
   mem-cache.max-file-size = 128 # cachovat se budou maximálně 128 kB velké soubory 

Monitoring

mod_status

Informace o aktuálních spojeních, propustnosti a také uptime zajišťuje mod_status. Ten zpřístupní jednoduchou stránku s těmito informacemi.

Konfigurace spočívá prakticky jen v načtení modulu a nastavením URL. Je možné přidat i javaskript, který seřadí seznam spojení.

   status.config-url      URL s konfigurací web serveru
   status.statistics-url  URL pro informace dostupné v čistém textu
   status.enable-sort     Zapnout/vypnout javaskript, který řadí seznam spojení
   status.status-url      URL s informacemi 

Příklad:

   status.config-url  = "/server-status-config"
   status.status-url  = "/server-status"
   status.enable-sort = "enable" 

mod_rrdtool

Lighttpd umí monitorovat samo sebe a poskytovat údaje o provozu přes rrdtool. Tento nástroj slouží ke generování grafů a v dokumentaci lze nalézt i bash skripty, které generují k těmto datům grafy.

Příklad nastavení:

   rrdtool.binary = "/usr/bin/rrdtool" # cesta k rrdtool
   rrdtool.db-name = "/var/www/lighttpd.rrd" # soubor s daty 

WebDAV

WebDAV je rozšíření HTTP protokolu, které umožňuje uživatelům pracovat se soubory na serveru. V Lighttpd nemá kompletní implementaci a neobsahuje některé operace. Pro ukládání informací o souborech a adresářích se používá sqlite databáze.

Příklad konfigurace:

   webdav.activate = "enable" # zapneme WebDAV
   webdav.is-readonly = "disable" # umožňíme zapisovat do sdíleného adresáře
   webdav.sqlite-db-name = "/var/run/lighttpd/lighttpd.webdav_lock.db" # databáze pro uchovávání informací o souborech 

Redirect a rewrite

Pokud si přejeme přesměrovat požadavek z jednoho URL na druhé, můžeme to udělat buď pomocí mod_rewrite nebo mod_redirect. Reagovat můžeme na část URL za lomítkem, takže jakoby v rámci jednoho webu.

Redirect se od rewrite liší tím, že odesílá klientovi hlavičku (výchozí 302) se správnou adresou, ten tam svůj požadavek nasměruje a změna se projeví i v řádku s adresou u uživatele. Rewrite změní adresu pouze interně ve web serveru, takže když nasměrujeme „/a“ na „/b“, v URL bude „/a“ a ve skutečnosti se bude pracovat s „/b“.

Příklad nastavení mod_redirect:

   #přesměrujeme obrázky na správnou adresu
   url.redirect = ( "/images" => "/media/imgs", "/index.php?page=([a-z0-9]*)" => "/mainpage/$1" ) 

Příklad nastavení mod_rewrite:

   # přesměrujeme index.php
   url.rewrite = ( "/mainpage/([a-z0-9]*)" => "/index.php?page=$1" ) 

Pravidel lze napsat více a oddělit je čárkou. Mod_rewrite nabízí více možností, protože dokáže pravidla aplikovat opakovaně.

   url.rewrite           stejné jako rewrite-once
   url.rewrite-once      aplikování pravidel jednou
   url.rewrite-repeate   aplikování pravidel několikrát 

Závěr

Vypisoval jsem všechna nastavení bez podmínek, která by omezovala funkce jen na určité domény a adresáře. Každý web server je jiný a pro samotnou funkci nejsou nutné.

Modulů pro Lighttpd je mnohem víc, ale jejich použití v praxi není tak časté. V článcích jsem se snažil vysvětlit, jak se tento web server konfiguruje a co od něj čekat, ale aspoň zběžné prostudování dokumentace by mělo být podmínkou užívání.

Užívám Lighttpd již přes rok a i s několika problémy, za které jsem si mohl víceméně sám, jsem s ním velmi spokojený a to jsem zdaleka nevyzkoušel všechno, co nabízí.

Odkazy

Našli jste v článku chybu?

16. 9. 2008 10:45

tojefuk (neregistrovaný)
Ano, jde - pomoci mod_magnet a skriptu v Lua. Nicmene kde je to jen trochu mozne, davam prednost vyctu regexu, nez pristupum na disk.
Viz diskuze pod prvnim clankem tohoto serialu, lighttpd-lehky-webserver.

13. 9. 2008 7:57

Radek (neregistrovaný)
jj, něco podobného se mi také přihodilo ...

Kolega používá windows a vývojové prostředí na projektu, kde mají složitou adresářovou strukturu a velké množství souborů. Refresh nebo build celého projektu byl velmi pomalý.

Nainstaloval si nějaký speciální tool, který mu vytvořil RAM-disk a projekt mu virtuálně přesunul tam a staral se i o to, aby se změny i zpětně ukládaly na disk. Výsledek si pochvaloval, že zrychlení bylo velmi výrazné.

Tak jsem si řekl, že to u sebe na linuxu zkusím také ... …





Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Vitalia.cz: Baletky propagují zdravotní superpostel

Baletky propagují zdravotní superpostel

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Lupa.cz: UX přestává pro firmy být magie

UX přestává pro firmy být magie

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Podnikatel.cz: Na poslední chvíli šokuje výjimkami v EET

Na poslední chvíli šokuje výjimkami v EET

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Podnikatel.cz: Babiš: E-shopy z EET možná vyjmeme

Babiš: E-shopy z EET možná vyjmeme