Názory k článku Lighttpd: Zajímavé moduly
-
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. -
Messa (neregistrovaný)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á.
-
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á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 :-)
