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>, Jakub Narebski <jnareb@gmail.com>
Subject: [RFC PATCHv3 00/10] gitweb: Simple file based output caching
Date: Tue, 16 Feb 2010 20:36:35 +0100 [thread overview]
Message-ID: <1266349005-15393-1-git-send-email-jnareb@gmail.com> (raw)
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.
This is third version (third release) of this series, and is available on
http://repo.or.cz/w/git/jnareb-git.git as 'gitweb/cache-kernel-v3' branch.
Earlier versions are available there as branches 'gitweb/cache-kernel'
and 'gitweb/cache-kernel-v2'. Previous version of this series was sent
to git mailing list as:
* [RFC PATCHv2 00/10] gitweb: Simple file based output caching
Message-Id: <1265711427-15193-1-git-send-email-jnareb@gmail.com>
http://thread.gmane.org/gmane.comp.version-control.git/139382
This version tries to do without
gitweb: Print to explicit filehandle (preparing for caching)
patch (or its equivalent). It does it by "capturing" output by changing
default filehandle (used for "print", "printf" and "write" without explicit
filehandle) via 'select($data_fh);' to point to in-memory file. This is
simplest possible solution, and does not require extra Perl modules.
Among other solutions are tie-ing *STDOUT to a class that captures output
(similar to what CGI::Cache does), or using PerlIO layers via push_layer() /
pop_layer() methods from (non-core) PerlIO::Util module (from CPAN).
This version also includes thorough (perhaps too thorough) error checking,
it has much more comments, should work correctly when two clients access the
same URL with an error condition (die_error is called), and it detaches
background process so even with mod_perl it would not generate zombies.
This version was tested a bit running under mod_cgi: that it generates page
correctly, that it gets page from cache, that cache expires correctly, that
stale page is being served, that "Generating..." page is generated correctly
and that it works.
There are a few KNOWN ISSUES: 'blame_incremental' action is not incremental
and does not work (perhaps JavaScript-based actions should be turned off
with current implementation of output cache?), and "Generating..." page
somehow does not get additional "." when waiting (but it works).
The following changes since commit 7e5eb8f1834722507e2d2171a253b78b1d924458
(in the 'master' branch of git.git repository):
Junio C Hamano (1):
Merge branch 'maint'
are available in the git repository at:
git://repo.or.cz/git/jnareb-git.git gitweb/cache-kernel-v3
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
Diffstat:
~~~~~~~~~
gitweb/README | 70 ++++
gitweb/cache.pm | 655 ++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 321 +++++++++++++++-
t/gitweb-lib.sh | 2 +
t/t9500-gitweb-standalone-no-errors.sh | 19 +
t/t9503-gitweb-caching.sh | 32 ++
t/t9503/test_cache_interface.pl | 404 ++++++++++++++++++++
t/test-lib.sh | 3 +
8 files changed, 1486 insertions(+), 20 deletions(-)
create mode 100644 gitweb/cache.pm
create mode 100755 t/t9503-gitweb-caching.sh
create mode 100755 t/t9503/test_cache_interface.pl
--
Jakub Narebski
git version 1.6.6.1
next reply other threads:[~2010-02-16 19:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-16 19:36 Jakub Narebski [this message]
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 ` gitweb: Simple file based output caching TODO (was: Re: [RFC PATCHv3 00/10] gitweb: Simple file based output caching) Jakub Narebski
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=1266349005-15393-1-git-send-email-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).