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 :-)

Seb

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,
EDINA,
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/