[EP-tech] Re: load throttling strategy
sf2 at ecs.soton.ac.uk
Tue Dec 16 16:26:25 GMT 2014
I don't reckon the "waiting" strategy is a good idea: 1- there's no
indication that server load will get better after waiting for n seconds,
2- if your thread is waiting, it can't take new connections (so clients
will be pilling up).
One strategy (given RG's issues) is to disable the on-demand
regeneration of such pages and only generate them offline (via
generate_views). Then no problems for the clients since eprints/apache
will only be serving cached pages (cached on-disk that is). And if you
really must, set-up Varnish or else in front of your repo...
If a page takes 10mins to regenerate then having it generated on-demand
by a client cannot be a good idea ;-)
Also out-of-interest I'd be curious to know of any stats showing that
visitors actually use the browse pages (ie. how often/how much). I kinda
see the point of having them for crawlers (then just have one browse
view, eg per year) but for users... meh :-)
On 16.12.2014 10:11, Ian Stuart wrote:
> On 16/12/14 10:05, Yuri wrote:
>> The best is to check the system load in the build page plugin/module, wait some seconds, and then go. Is there some documentation somewhere on Eprints strategies on views page rebuilds?
> The only thing I'm aware one can do is define the number of days
> view-pages are considered "valid" for, before being automatically rebuilt.
> Ian Stuart.
> Developer: ORI, RJ-Broker, and OpenDepot.org
> Bibliographics and Multimedia Service Delivery team,
> The University of Edinburgh.
> http://edina.ac.uk/ 
> This email was sent via the University of Edinburgh.
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech 
> *** Archive: http://www.eprints.org/tech.php/ 
> *** EPrints community wiki: http://wiki.eprints.org/ 
> *** EPrints developers Forum: http://forum.eprints.org/ 
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Eprints-tech