On Wed, Mar 12, 2014 at 6:13 PM, Andreas Kupries <andre...@activestate.com>wrote:
> 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. > FWIW: i was scratching down ideas for this very idea today for the libfossil CGI demos because i don't like the memory cost of generate ZIP files from script code. Caching the (say) 10 most recent ZIPs could alleviate some of my load concerns. It need not be a synchable table, nor in one which survives a rebuild. Note that I actually see this as a possible complement to the load mgmt > feature. > The cache would help if demand is high for a small number of > revisions, whereas load mgmt would kick in and restrict load if the > access pattern of revisions is sufficiently random/spread out to > negate the cache (i.e. cause it to thrash). > +1 > would require more work to set up and admin. And might be a problem > for the truly dynamic parts of the fossil web ui. An integrated cache > just for the assets which are expensive to compute and yet > (essentially) static does not have these issues. > In my experience, most proxies won't cache for requests which have URL parameters. Whether or not that's generally true, i can't say. For static content (lots of what fossil serves is static), the URLs can/should be written as /path/arg1/arg2, rather than /path?arg1=...&arg2=..., to make them "potentially more cacheable". -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
