compress.max-filesize = 4096 znamená maximální velikost souboru, který bude komprimován? Co když tento řádek neuvedu, komprimují se pak všechny soubory?
Názory k článku
Lighttpd: Zajímavé moduly
12. 9. 2008 1:26
Nový
Velikost komprimovaného souboru
celé vlákno
Pochopil jsem dobře, že
12. 9. 2008 2:16
Nový
Re: Velikost komprimovaného souboru
celé vlákno
Pochopil si dobře. Pokud se hodnota neuvede, tak se použije maximální a ta je 128MB.
Blato (neregistrovaný)
12. 9. 2008 8:39
Nový
rewrite
celé vlákno
Zajimalo by mě, jestli jde dosahnout pomocí mod_rewrite tohoto:
(mod_rewrite pod apachem)
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ index.php [L,QSA]
(mod_rewrite pod apachem)
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ index.php [L,QSA]
12. 9. 2008 13:46
Nový
Re: rewrite
celé vlákno
V Apachi nejsem tak zběhlej, takže si nejsem jistej co to pravidlo znamená, ale neni to něco jako mám v tom příkladu? Tedy 'url.rewrite = ( "/mainpage/([a-z0-9]*)" => "/index.php?page=$1" )' ?
13. 9. 2008 10:07
Nový
Re: rewrite
celé vlákno
Pokud vim tak lighttpd pracuje v rewrite jen s RegExp, takze test zjistujici jestli URI ukazuje na soubor (-f) nebo adresar (-d) tam udelat nejdou. Prinejmensim me se to nepodarilo a musel jsem explicitne vyjmenovat vsechny cesty ktere se maji servirovat primo (treba JS, CSS soubory a obrazky) a zbytek poslat do index.php.
Podpora pro mod_rewrite kompatibilni syntaxi by v mych ocich byla pro lighttpd byla killer-feature ktera by umoznila jeho nasazeni i pro komplexni aplikace ktere si nezridka samy generuji Rewrite pravidla v zavislosti na konkterni konfiguraci.
Podpora pro mod_rewrite kompatibilni syntaxi by v mych ocich byla pro lighttpd byla killer-feature ktera by umoznila jeho nasazeni i pro komplexni aplikace ktere si nezridka samy generuji Rewrite pravidla v zavislosti na konkterni konfiguraci.
tojefuk (neregistrovaný)
16. 9. 2008 10:45
Nový
Re: rewrite
celé vlákno
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.
Viz diskuze pod prvnim clankem tohoto serialu, lighttpd-lehky-webserver.
wagoon (neregistrovaný)
12. 9. 2008 13:41
Nový
mod_mem_cache a X-tag
celé vlákno
pokud pouziju mod_mem_cache, bude server posilat spravny Xtag? Nemusi se kvuli nemu divat na disk?
Messa (neregistrovaný)
12. 9. 2008 16:42
Nový
mod_mem_cache
celé vlákno
mod_mem_cache jistě má svůj smysl, ale nebylo by zrovna pro kešování obrázků a CSS souborů lepší spolehnout se na operační systém a jeho diskovou cache? To by daný soubor byl v paměti jen jednou. Při použití této cache je soubor v paměti dvakrát - jednou v cache operačního systému a podruhé v cache webserveru. Pokud je požadavků tolik, že cache OS dlouho nevydrží, pak cache webserveru také ne a její případné zvětšení na výkonu serveru asi taky moc nepřidá.
12. 9. 2008 21:25
Nový
Re: mod_mem_cache
celé vlákno
Dobrá poznámka.. takhle jsem nad tím neuvažoval.
Radek (neregistrovaný)
13. 9. 2008 7:57
Nový
Re: mod_mem_cache
celé vlákno
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ám sice menší projekt, ale build travá cca 1min a tak by bylo také dobré ušetřit ... A tak jsem si udělal ram disk, zkopíroval na něj projekt a výsledek? ... nic ... možná mi to přišlo ještě pomalejší :-)
Chvíli jsem dumal proč, ale ono je to asi jasné ... mám 4G RAM ... efektivně zabráno necelé 1G a zbytek je cache OS ... tedy, já už tam ten "RAM disk" měl před tím, zcela transparentně a bez práce :-)
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ám sice menší projekt, ale build travá cca 1min a tak by bylo také dobré ušetřit ... A tak jsem si udělal ram disk, zkopíroval na něj projekt a výsledek? ... nic ... možná mi to přišlo ještě pomalejší :-)
Chvíli jsem dumal proč, ale ono je to asi jasné ... mám 4G RAM ... efektivně zabráno necelé 1G a zbytek je cache OS ... tedy, já už tam ten "RAM disk" měl před tím, zcela transparentně a bez práce :-)

