On Mon, Jul 7, 2014 at 12:44 PM, Julian Foad <julianfoad_at_btopenworld.com>
wrote:
>
> C-Mike, my understanding is that F7 comprehensively beats F6 speed, by
> large factors around x1.5 and more, in the kind of scenarios it's designed
> for. Caching is an assumed part of the design. I don't know how much it
> needs for what scenarios, or what you mean by 'non-trivial' or 'ginormous',
> but probably not as much as you might be led to think. I suggest you first
> look at Stefan's recent-ish test results [1] and other recent threads.
>
> The only concerns about speed are about scenarios where it doesn't match
> F6 speed. While many scenarios are faster, some are slower, especially with
> the currently-default small cache size. Ivan reported some such scenarios
> [2].
>
> My general observation is that wider testing is needed to draw firm
> conclusions.
>
>
My feeling, which could be wrong, is that caching is of little value to me.
All of the sites I work with are using Apache. Most of them have hundreds
if not thousands of repositories. Typically all of them are being used
each day and there are thousands of users hitting the site.
I just cannot envision scenarios where caching could ever be that helpful.
Or that I could have enough RAM to make the caching useful while still
servicing hundreds of simultaneous Apache connections.
On Linux, we also use prefork MPM as that is the only one that ever seemed
stable over long periods. I am guessing that the worker MPM could be tuned
to work well but we'd run into various problems with RAM not being released
and/or incompatibility with other modules running in the server and always
went back to prefork.
FWIW, I am fine with the idea of making a repository format that can give
great performance when caching is enabled. I tend to think it should not
be our default format unless it performs just as well as what it is
replacing when cache is not being used, or is small.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2014-07-07 19:05:41 CEST