I really wasn't trying to work backwards from a benchmark. It was
more of an analysis of the design, and the benchmarks bore it out.
It's sort of like coming up with a theory in science - if you can't get
any experimental data to back up the theory, you're in big trouble.
But if you can at least point out the existence of some experiments
that are consistent with your theory, it means your theory may be true.
The best would be to have other people do the same tests and see if they
see the same trend. If no-one else sees this trend, then I'd really
have to re-think my analysis.
Another way to look at it - as you say below MRU is going to be in
mod_perl-2.0. ANd what is the reason for that? If there's no performance
difference between LRU and MRU why would the author bother to switch
to MRU. So, I'm saying there must be some benchmarks somewhere that
point out this difference - if there weren't any real-world difference,
why bother even implementing MRU.
I claim that my benchmarks point out this difference between MRU over
LRU, and that's why my benchmarks show better performance on speedycgi
than on mod_perl.
Sam
- SpeedyCGI uses MRU, mod_perl-2 will eventually use MRU.
> On Thu, 21 Dec 2000, Sam Horrocks wrote:
>
> > > Folks, your discussion is not short of wrong statements that can be easily
> > > proved, but I don't find it useful.
> >
> > I don't follow. Are you saying that my conclusions are wrong, but
> > you don't want to bother explaining why?
> >
> > Would you agree with the following statement?
> >
> > Under apache-1, speedycgi scales better than mod_perl with
> > scripts that contain un-shared memory
>
> I don't know. It's easy to give a simple example and claim being better.
> So far whoever tried to show by benchmarks that he is better, most often
> was proved wrong, since the technologies in question have so many
> features, that I believe no benchmark will prove any of them absolutely
> superior or inferior. Therefore I said that trying to tell that your grass
> is greener is doomed to fail if someone has time on his hands to prove you
> wrong. Well, we don't have this time.
>
> Therefore I'm not trying to prove you wrong or right. Gunther's point of
> the original forward was to show things that mod_perl may need to adopt to
> make it better. Doug already explained in his paper that the MRU approach
> has been already implemented in mod_perl-2.0. You could read it in the
> link that I've attached and the quote that I've quoted.
>
> So your conclusions about MRU are correct and we have it implemented
> already (well very soon now :). I apologize if my original reply was
> misleading.
>
> I'm not telling that benchmarks are bad. What I'm telling is that it's
> very hard to benchmark things which are different. You benefit the most
> from the benchmarking when you take the initial code/product, benchmark
> it, then you try to improve the code and benchmark again to see whether it
> gave you any improvement. That's the area when the benchmarks rule and
> their are fair because you test the same thing. Well you could read more
> of my rambling about benchmarks in the guide.
>
> So if you find some cool features in other technologies that mod_perl
> might adopt and benefit from, don't hesitate to tell the rest of the gang.
>
> ----
>
> Something that I'd like to comment on:
>
> I find it a bad practice to quote one sentence from person's post and
> follow up on it. Someone from the list has sent me this email (SB> == me):
>
> SB> I don't find it useful
>
> and follow up. Why not to use a single letter:
>
> SB> I
>
> and follow up? It's so much easier to flame on things taken out of their
> context.
>
> it has been no once that people did this to each other here on the list, I
> think I did too. So please be more careful when taking things out of
> context. Thanks a lot, folks!
>
> Cheers...
>
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
