[RFC PATCHv2 00/10] gitweb: Simple file based output caching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This 10 patches long patch series is intended 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 second version (second release) of this series; previous is
available at http://repo.or.cz/w/git/jnareb-git.git as 'gitweb/cache-kernel'
branch.  It was sent as:
* [RFC PATCH 00/10] gitweb: Simple file based output caching
  Message-Id: <cover.1264198194.git.jnareb@xxxxxxxxx>
  http://thread.gmane.org/gmane.comp.version-control.git/136913/focus=136917
(note however that v1 series of emails is lacking one of patches because
it was over VGER anti-spam size limit for messages).

This version tries to do without 
  gitweb: Print to explicit filehandle (preparing for caching)
patch, by capturing output using either PerlIO layers manipulated
using PerlIO::Util if this module is available, or direct manipulation
of *STDOUT if PerlIO::Util isn't available.  One of the goals of this
series is then decide whether it is worth to have explicit filehandle
in print statements in gitweb, or not; if the complexity is worth not
having to deal with straightforward but quite intrusive (and large)
patch.

As the earlier version was inspired by file-based caching in
Cache::Cache, this one is inspired by file-based caching in more
modern CHI (unified cache interface).

It still lacks POD for gitweb/cache.pm (would it be needed, or would
comments be enough), and gitweb/cache.pm still ties rather heavily
into gitweb (following still what was in original J.H. (mega)patch).

It *does* have quite detailed commit messages, as opposed to v1 of
this series, where some commits were described only in comment section
of emails containing them.  It is also very configurable (Pasky, this
would probably be of interest to you, as you didn't want to have 
"Generating..." pages enabled), even more than in original patch
by J.H.


NOTE: there are quite a bit of _API_ tests, but I have not tested gitweb
output with caching enabled extensively (thats how bug in "Generating..."
slipped through - for details see comments in last patch).  I have tested
that caching works around 4th patch in series, in that it doesn't cause
errors and displays page (here the lack of error handling is decidely
unhelpful), and that it displays the time when page was generated.  As I
have installed PerlIO::Util using local::lib, i.e. locally in ~/perl5,
I think that what I have been testing was the "*STDOUT munging" method
of capturing gitweb output.  (See "Capturing gitweb output" section
in PATCHv2 04/10).


This series is based on commit 8424981934c415bd20643de9cc932bd348dfb115:
(in the 'master' branch of git.git repository)
  Jeff King (1):
        Fix invalid read in quote_c_style_counted

and is available in the git repository at:

  git://repo.or.cz/git/jnareb-git.git gitweb/cache-kernel-v2

Jakub Narebski (10):
  gitweb: href(..., -path_info => 0|1)
  gitweb/cache.pm - Very simple file based caching
  gitweb/cache.pm - Stat-based cache expiration
  gitweb: Use Cache::Cache compatible (get, set) output caching
  gitweb/cache.pm - Adaptive cache expiration time
  gitweb: Use CHI compatible (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

Note that compared to previous version of this series, this version
lacks initial commit.
  gitweb: Print to explicit filehandle (preparing for caching)
This is a bit of an experiment if we can do caching without large patch
to gitweb upfront, and to decide whether tradeoff (more complicated
capturing) is worth it.

Also, one of the commits:
  gitweb/cache.pm - Serve stale data when waiting for filling cache (WIP)
was split into two separate commits:
  gitweb/cache.pm - Serve stale data when waiting for filling cache
  gitweb/cache.pm - Regenerate (refresh) cache in background
one serving stale data (in processes waiting for cache to be filled, 
aka readers), and one adding background cache regeneration. 

After previous series I have sent additional (PATCH 11/10) patch:
  gitweb: Ajax-y "Generating..." page when regenerating cache (WIP)
This patch would require rework to apply to this new series.

Diffstat:
~~~~~~~~~
 gitweb/README                          |   70 +++++
 gitweb/cache.pm                        |  530 ++++++++++++++++++++++++++++++++
 gitweb/gitweb.perl                     |  305 +++++++++++++++++-
 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        |  380 +++++++++++++++++++++++
 t/test-lib.sh                          |    3 +
 8 files changed, 1325 insertions(+), 16 deletions(-)
 create mode 100644 gitweb/cache.pm
 create mode 100755 t/t9503-gitweb-caching.sh
 create mode 100755 t/t9503/test_cache_interface.pl

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]