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
next prev 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).