git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Cc: John 'Warthog9' Hawley <warthog9@eaglescrag.net>,
	John 'Warthog9' Hawley <warthog9@kernel.org>,
	Petr Baudis <pasky@suse.cz>
Subject: gitweb: Simple file based output caching TODO (was: Re: [RFC PATCHv3 00/10] gitweb: Simple file based output caching)
Date: Sun, 28 Feb 2010 03:54:49 +0100	[thread overview]
Message-ID: <201002280354.51366.jnareb@gmail.com> (raw)
In-Reply-To: <1266349005-15393-1-git-send-email-jnareb@gmail.com>

On Tue, 16 Feb 2010, Jakub Narebski wrote:
> This 10 patches long patch series is intended (yet) as preliminary version
> for splitting large 'gitweb: File based caching layer (from git.kernel.org)'
> mega-patch by John 'Warthog9' Hawley aka J.H., by starting small and
> adding features piece by piece.

[...]
> Shortlog:
> ~~~~~~~~~
> Jakub Narebski (10):
>   gitweb: href(..., -path_info => 0|1)
>   gitweb/cache.pm - Very simple file based cache
>   gitweb/cache.pm - Stat-based cache expiration
>   gitweb: Use Cache::Cache compatibile (get, set) output caching
>   gitweb/cache.pm - Adaptive cache expiration time
>   gitweb: Use CHI compatibile (compute method) caching
>   gitweb/cache.pm - Use locking to avoid 'cache miss stampede' problem
>   gitweb/cache.pm - Serve stale data when waiting for filling cache
>   gitweb/cache.pm - Regenerate (refresh) cache in background
>   gitweb: Show appropriate "Generating..." page when regenerating cache

Here is the list of things that needs to be addressed in the future 
next (v4) version of this series, hopefully finally not an RFC.

* The caching engine (GitwebCache::SimpleFileCache) starts with default
  expire time of "never" (-1), while later it uses gitweb defaults when
  adaptive caching lifetime is added (20 / 1200 seconds).  This (slight)
  inconsistency should be fixed, either by using default of "never", or
  by using gitweb defaults for caching engine defaults in both patches:
    gitweb/cache.pm - Stat-based cache expiration
    gitweb/cache.pm - Adaptive cache expiration time

  Note that caching engine defaults are *independent* of gitweb's 
  defaults in %cache_options.

* Describe (better than it is now) in comments or in commit message
  why Temp::File is used for 'atomic write' _without_ locking (even
  when there might be more than one process (re)generating the same
  cache entry simultaneously).

* [improvement].  When using locking after
    gitweb/cache.pm - Use locking to avoid 'cache miss stampede' problem
  it is ensured that only one process would (re)generate cache entry.
  Therefore Temp::File is not needed for temporary file; the temporary
  file can have constant name.  This should improve performance a bit.

  But this might be unnecessary complication.

* Show information about when page was generated in the footer always
  when caching is enabled; currently it is shown only if caching *and*
  'timed' feature is enabled 
    gitweb: Use Cache::Cache compatibile (get, set) output caching

* Actually check that using alternate caching engine works.  It can be
  done (what is described in gitweb/README) by setting $cache to either
  cache engine class (package) name, or to cache object (instantiated
  cache).

* [cleanup] Remove commented out alternate solutions (commented out
  code).

* Benchmark overhead of caching, and performance of caching, perhaps for
  different caching engines including original patch by J.H.

John, Pasky, do you have any further comments / requests?
-- 
Jakub Narebski
Poland

  parent reply	other threads:[~2010-02-28  2:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 19:36 [RFC PATCHv3 00/10] gitweb: Simple file based output caching Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 01/10] gitweb: href(..., -path_info => 0|1) Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 02/10] gitweb/cache.pm - Very simple file based cache Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 03/10] gitweb/cache.pm - Stat-based cache expiration Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 05/10] gitweb/cache.pm - Adaptive cache expiration time Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 06/10] gitweb: Use CHI compatibile (compute method) caching Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 07/10] gitweb/cache.pm - Use locking to avoid 'cache miss stampede' problem Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 08/10] gitweb/cache.pm - Serve stale data when waiting for filling cache Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 09/10] gitweb/cache.pm - Regenerate (refresh) cache in background Jakub Narebski
2010-02-16 19:36 ` [RFC PATCHv3 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache Jakub Narebski
2010-02-18 22:01 ` [RFC PATCHv3 00/10] gitweb: Simple file based output caching J.H.
2010-02-19  0:14   ` Jakub Narebski
2010-02-28  2:54 ` Jakub Narebski [this message]
2010-02-28 11:51   ` gitweb: Simple file based output caching TODO Jakub Narebski
2010-02-28 12:07   ` gitweb: Simple file based output caching TODO (was: Re: [RFC PATCHv3 00/10] gitweb: Simple file based output caching) Petr Baudis

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=201002280354.51366.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --cc=warthog9@eaglescrag.net \
    --cc=warthog9@kernel.org \
    /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).