git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Julio Lajara" <julio.lajara@alum.rpi.edu>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Anders Kaseorg" <andersk@mit.edu>,
	git@vger.kernel.org,
	"Pavan Kumar Sunkara" <pavan.sss1991@gmail.com>
Subject: Re: [PATCH/RFC] gitweb: allow configurations that change with each request
Date: Mon, 2 Aug 2010 21:35:57 +0200	[thread overview]
Message-ID: <201008022135.58287.jnareb@gmail.com> (raw)
In-Reply-To: <20100731030159.GD906@burratino>

On Sat, 31 Jul 2010, Jonathan Nieder wrote:

> gitolite's contrib/gitweb/gitweb.conf includes:
> 
> 	$ENV{GL_USER} = $cgi->remote_user || "gitweb";
> 
> which is useful for setups where a user has to be authenticated
> to access certain repos.  Perhaps other typical configurations
> change per session in other ways, too.
> 
> v1.7.2-rc2~6 (gitweb: Move evaluate_gitweb_config out of run_request,
> 2010-07-05) broke such configurations for a speedup, by loading
> the configuration once per FastCGI process.
> 
> Probably in the end there should be a way to specify in the
> configuration whether a particular installation wants the speedup or
> the flexibility.  But for now it is easier to just undo the relevant
> change.
> 
> This partially reverts commit 869d58813b24c74e84c9388041eafcef40cb51e4.

Why only *partially* reverts...

...ah, I see, I did "while at it" change fixing timer and number of git
commands info for persistent environments (i.e. gitweb run as FastCGI
script).
 
> Reported-by: Julio Lajara <julio.lajara@alum.rpi.edu>
> Analysis-by: Jakub Narebski <jnareb@gmail.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

Reluctantly-acked-by: Jakub Narebski <jnareb@gmail.com>

> ---
> Jakub Narebski wrote:
> 
> > I wonder if it would be possible to 
> > re-enable this feature (which I think is needed to be able to use
> > $cgi->remote_user) but without having all pay the [slight] performance
> > penalty of including (and I think parsing) config file once per each
> > request.
> 
> I dunno.  Maybe this would be a good place to start.

Currently this is non-issue; the eventual performance penalty is I guess
very small.

The problem would be with adding caching support to gitweb.  While
default GitwebCache::* caching engine should have low startup cost, 
the CHI generic caching interface that one might want to use instead
uses Moose (Mouse with Any::Moose?) for OOP, which imposes some startup
cost.  One enables and configures output caching in gitweb config, so
if gitweb config would be read once per run then cache interface could
be started once per run, not once per request.
 
Nevertheless this change is backwards incompatibile change, and should
probably wait for 1.7.3 (pity that 1.7.2 was so recently released).


One solution I can think of (still backwards incompatibile) would be to
provide $per_request_config variable, which would hold anonymous sub
with parts of config that need to be done per request (this should work
with global variables (our), but I think it wouldn't work with lexical
variables (my)).  For example gitolite's contrib/gitweb/gitweb.conf would
then include:

  $per_request_config = sub {
  	$ENV{GL_USER} = $cgi->remote_user || "gitweb";
  }

What do you think about it?

>  gitweb/gitweb.perl |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e0e9532..300c4b1 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1060,8 +1060,12 @@ sub run_request {
>  	reset_timer();
>  
>  	evaluate_uri();
> +	evaluate_gitweb_config();
>  	check_loadavg();
>  
> +	# $projectroot and $projects_list might be set in gitweb config file
> +	$projects_list ||= $projectroot;
> +
>  	evaluate_query_params();
>  	evaluate_path_info();
>  	evaluate_and_validate_params();
> @@ -1109,12 +1113,8 @@ sub evaluate_argv {
>  
>  sub run {
>  	evaluate_argv();
> -	evaluate_gitweb_config();
>  	evaluate_git_version();
>  
> -	# $projectroot and $projects_list might be set in gitweb config file
> -	$projects_list ||= $projectroot;
> -
>  	$pre_listen_hook->()
>  		if $pre_listen_hook;
>  

That reminds me: '$projects_list ||= $projectroot;' line should be put,
I think, inside evaluate_gitweb_config().  But that of course should not
be done in this patch.

-- 
Jakub Narebski
Poland

  reply	other threads:[~2010-08-02 19:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26  4:55 Potential bug in gitweb 1.7.2 Julio Lajara
2010-07-26  5:08 ` Jonathan Nieder
2010-07-26  9:27   ` Anders Kaseorg
2010-07-26 13:10     ` Julio Lajara
2010-07-26 13:36       ` Jakub Narebski
2010-07-26 13:39         ` Ævar Arnfjörð Bjarmason
2010-07-26 13:52           ` Julio Lajara
2010-07-26 14:23             ` Jakub Narebski
2010-07-31  3:01               ` [PATCH/RFC] gitweb: allow configurations that change with each request Jonathan Nieder
2010-08-02 19:35                 ` Jakub Narebski [this message]
2010-08-02 21:01                   ` Jonathan Nieder
2010-08-02 21:25                     ` Jakub Narebski
2010-07-26 15:23     ` Potential bug in gitweb 1.7.2 Jonathan Nieder
2010-07-26 18:50       ` Anders Kaseorg
2010-07-27  0:09         ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201008022135.58287.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=andersk@mit.edu \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=julio.lajara@alum.rpi.edu \
    --cc=pavan.sss1991@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).