> The current Fossil implementation runs a separate process for each HTTP > request. So an in-memory cache wouldn't be helpful. It has to be disk- > based.
Does not FastCGI do exactly the opposite? RR 2014-03-12 18:25 GMT+01:00 Richard Hipp <d...@sqlite.org>: > > > > On Wed, Mar 12, 2014 at 1:13 PM, Andreas Kupries <andre...@activestate.com > > wrote: > >> On Wed, Mar 12, 2014 at 6:40 AM, Richard Hipp <d...@sqlite.org> wrote: >> >> > And if you have alternative suggestions about how to keep a light-weight >> > host running smoothly under a massive Fossil request load, please post >> > follow-up comments. >> >> How sensible do you think would it be to have a (limited-size) >> (in-memory|disk) cache to hold the most recently requested tarballs ? >> That way a high-demand tarball, etc. would be computed only once and >> then served statically from the cache. >> > > It's on my to-do list, actually. The idea is to have a separate database > that holds the cache. And yes it is complementary to the load management > feature. > > >> >> Side note: While the same benefits could be had by putting a regular >> web cache in front of the fossil server, .... > > > No they can't actually, at least not by any technology I'm aware of. The > problem is that these request must be authenticated. Downloads might be > only authorized for certain users. If an authorized user does a download, > and squid caches it, some other unauthorized user might be able to obtain > the download from cache. > > Even if downloads are currently authorized for anybody (which is the > common case, at least on public repos), I don't think you want them being > cached, since to do so would mean that turning off public downloads would > be ineffective until the caches all expired. > > I mentioned in-memory and disk ... I can see that a two-level scheme >> here ... A smaller in-memory cache for the really high-demand pieces >> with LRU, and a larger disk cache for the things not so much in-demand >> at the moment, but possibly in the future. The disk cache could >> actually be much larger (disks are large and cheap these days), this >> would help with random access attacks (as they would become >> asymptotically more difficult as the disk cache over time extends its >> net of quickly served assets). >> >> > > The current Fossil implementation runs a separate process for each HTTP > request. So an in-memory cache wouldn't be helpful. It has to be > disk-based. > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
