Subject: Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)

From: Petr Baudis <[email-masked]>
Date: Mon, 25 Jan 2010 14:56:53 +0100

On Mon, Jan 25, 2010 at 02:48:26PM +0100, Jakub Narebski wrote:
> Now those patches (mine and J.H. both) make gitweb use locking
> (it is IIRC configurable in J.H. patch) to make only one process
> generate the page if it is missing from cache, or is stale.  Now
> if it is missing, we have to wait until it is generated in full
> before being able to show it to client.  While it is possible to
> "tee" output (using PerlIO::tee, or Capture::Tiny, or tie like
> CGI::Cache) writing it simultaneously to browser and to cache for 
> the process that is generating data, it is as far as I understand
> it impossible for processes which are waiting for data.  Therefore
> the need for "Generating..." page, so the user does not think that
> web server hung or something, and is not generating output.

Ah, ok, so the message is there to cover up for a technical problem. ;-)
I didn't quite realize. Then, it would be great to tweak the mechanisms
so that the user does not really have to wait.

So, I wonder about two things:

(i) How often does it happen that two requests for the same page are
received? Has anyone measured it? Or is at least able to make
a minimally educated guess? IOW, isn't this premature optimization?

(ii) Can't the locked gitwebs do the equivalent of tail -f?

P.S.: Again the disclaimer - if this is "too hard", it's better to
accept patches like they are, then improve this later. But perhaps
a better solution would be not to clutter the code by optimizing this
case at all if it's not clear it really matters in the real world.

				Petr "Pasky" Baudis