nginx_slowfs_cache

jb justinbeech at gmail.com
Sun Apr 19 13:16:58 UTC 2015


At least in my experience unless your most used static files exceed in size
your available RAM, or are changing, they are effectively cached by the OS
anyway.

So storing them on a ram disk is really doing the same or worse job than
just letting the OS store them and serve them from its file cache memory
pages. Plus the OS has the advantage of knowing which are less frequently
used and can be purged.

On Sun, Apr 19, 2015 at 11:12 PM, wishmaster <artemrts at ukr.net> wrote:

>
>
>
>  --- Original message ---
>  From: "Rainer Duffner" <rainer at ultra-secure.de>
>  Date: 19 April 2015, 15:53:29
>
>
>
> >
> > > Am 19.04.2015 um 13:14 schrieb wishmaster :
> > >
> > > Hi,
> > >
> > > Today after upgrading from nginx version 1.6.x to 1.7.x I have got a
> segmentation fault. After short investigation the culprit was found. It is
> module by Frikle - nginx_slowfs_cache.
> > >
> > > Is anybody has the same issue? Is this module is obsolete?
> >
> >
> >
> > Can you describe your use-case for it?
> >
> > And whether you saw a performance-boost from it, compared to other
> alternatives?
> >
> >
> > I wouldn’t say it’s useless these days, but I view it as a bit „exotic“.
>
>    Read this from official website:
>
> About
> =====
> `ngx_slowfs_cache` is `nginx` module which allows caching of static files
> (served using `root` directive). This enables one to create fast caches
> for files stored on slow filesystems, for example:
>
> - storage: network disks, cache: local disks,
> - storage: 7,2K SATA drives, cache: 15K SAS drives in RAID0.
>
> **WARNING! There is no point in using this module when cache is placed
> on the same speed disk(s) as origin.**
> ====
>
> I use RAM disk for this cache. Yes, it is fast enough.
> Do you know any alternatives?
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150419/c95a2d2f/attachment.html>


More information about the nginx mailing list