Well for starters this isn't exactly a reinvention of the wheel, and
this isn't something "new" per-se. This code has been actively running
on git.kernel.org for something like 3 - 4 years so there's something to
be said for the devil we know and understand. As well using the other
caching strategies involves adding dramatically more complex
interactions with caching layer. The caching layer is actually quite
specific to how git + gitweb works and solves more than just "caching"
on the surface. Specifically it solves the stampeding herd problem
which would have to be solved either way even if I didn't implement my
own caching, and since I had to do that caching was barely a step beyond
that to implement.
True but these are *VERY* different caching strategies than the one I've
got here, yes it's using files as a backend but it's doing so with
specific goals in mind. As I've said I plan to integrate Lea's
memcached based caching into this in the future and that has different
advantages and disadvantages.
At the end of the day the "normal" caching engines aren't as efficient
as mine and there is the case the very high performance sites are going
to have to investigate a number of different solutions to see what works
best for them. Mine is also *dramatically* simpler to setup as well,
turn it on, point it at a directory and your done.
There's pitfalls if I do it myself, or I use one of the other "common"
perl modules. I did it this way years ago, I've maintained it and it
works pretty well. I won't admit that it's the smartest caching engine
on the planet, far from it, but it has evolved specifically for gitweb
and that itself saves me a lot of pitfalls from cache engine + gitweb
integration.
Yes, but as can be seen from how you enable various other caching
engines the setup of those is non-trivial, this is and either way
caching *HAS* to be explicitly turned on by the admin/user since they
are going to have to do *some* configuration, or at least be aware that
their webapp is going to chew up some sort of resource.
I thought about that 3 years ago, and decided it wasn't a good option
for gitweb. Why? There's too many assumptions throughout the code that
when you do a print it will go immediately out. Things like error
messages and such. Breaking out the prints into prints (which will do
what is expected) and passing around the output in the $output variables
makes it a lot simpler easier to differentiate about how / what your
looking at and a *LOT* easier to debug.
That's fine. The issues your raising aren't new though, and stem back
to before I created gitweb-caching, got rehashed with Lea's patches and
not surprisingly are back on the table now. Like I said above, there is
no one caching strategy that's perfect in all cases here and that's
again why I eventually plan to merge Lea's changes (which uses
memcached) in as well, I'm just trying to get code that I'm getting
considerable demand for, that's proven, upstream.
- John 'Warthog9' Hawley
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
