From: "J.H." <warthog9@eaglescrag.net>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org,
"John 'Warthog9' Hawley" <warthog9@kernel.org>,
Petr Baudis <pasky@suse.cz>
Subject: Re: [RFC PATCHv3 00/10] gitweb: Simple file based output caching
Date: Thu, 18 Feb 2010 14:01:12 -0800 [thread overview]
Message-ID: <4B7DB8A8.4020306@eaglescrag.net> (raw)
In-Reply-To: <1266349005-15393-1-git-send-email-jnareb@gmail.com>
> Shortlog:
> ~~~~~~~~~
> Jakub Narebski (10):
> gitweb: href(..., -path_info => 0|1)
This still looks fine to me.
> gitweb/cache.pm - Very simple file based cache
This looks fine to me, and I'm much more keen on using the CHI interface.
> gitweb/cache.pm - Stat-based cache expiration
- I think having expires time at -1 (never) is a dangerous default. I
think having it as an option is fine, but setting this to something like
6 months may be a better option. I wouldn't expect this to be an issue
in reality, but I can just see someone screwing up and having a cache
system that *never* expires. I think I'd rather see something long vs.
never. But that's just my opinion.
- This does have the problem (though this gets fixed later on, again)
that it would return invalid if there's a process already updating the
cache. This might need to be fixed later to understand the locking
structures on what is/isn't valid (this is mostly a note for me while I
read through the patches)
> gitweb: Use Cache::Cache compatibile (get, set) output caching
- It might be worth (in a later patch) enabling the PerlIO layers as
there was a significant speed improvement in using them, despite their
non-standardness.
- What if you want to use a different caching library but don't want
cache.pm ? That first bit of "if ($caching_enabled) {" might need to be
wrapped to figure out if we are using our inbuilt caching or an external
caching system. (just thinking out loud)
Looks fine to me.
> gitweb/cache.pm - Adaptive cache expiration time
is the commented:
#return &{$self->{'check_load'}}();
intended in check_load() ?
otherwise this looks fine to me.
> gitweb: Use CHI compatibile (compute method) caching
Looks fine to me. I think it's fine where it's at in the order myself.
> gitweb/cache.pm - Use locking to avoid 'cache miss stampede' problem
Looks fine to me.
> gitweb/cache.pm - Serve stale data when waiting for filling cache
Looks fine to me.
> gitweb/cache.pm - Regenerate (refresh) cache in background
Looks good to me.
> gitweb: Show appropriate "Generating..." page when regenerating cache
I've got a couple of things that will need to be added on top of this
(mainly to try and guess if the client is dumb or smart) so that if it
won't support generating... as expected it doesn't get it. But that can
come in a later patch.
This looks fine to me.
>
> 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
>
next prev parent reply other threads:[~2010-02-18 22:01 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 ` J.H. [this message]
2010-02-19 0:14 ` [RFC PATCHv3 00/10] gitweb: Simple file based output caching 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=4B7DB8A8.4020306@eaglescrag.net \
--to=warthog9@eaglescrag.net \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
--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).