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
