A new feature was recently added to Fossil that allows it to deny expensive
requests (such as blame or tarball on a large repository) if the server
load average is too high. See
http://www.fossil-scm.org/fossil/doc/tip/www/server.wiki#loadmgmt for
further information.
This new feature was
On Wed, Mar 12, 2014 at 6:40 AM, Richard Hipp d...@sqlite.org wrote:
A new feature was recently added to Fossil that allows it to deny expensive
requests (such as blame or tarball on a large repository) if the server
load average is too high. See
On Wed, Mar 12, 2014 at 1:13 PM, Andreas Kupries
andre...@activestate.comwrote:
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
On Wed, Mar 12, 2014 at 6:13 PM, Andreas Kupries
andre...@activestate.comwrote:
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
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
On Wed, Mar 12, 2014 at 1:26 PM, Stephan Beal sgb...@googlemail.com wrote:
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
On Wed, Mar 12, 2014 at 6:31 PM, Ramon Ribó ram...@compassis.com wrote:
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?
FastCGI requires
7 matches
Mail list logo
