Sam Horrocks wrote:
>
> A few things:
>
> - In your results, could you add the speedycgi version number (2.02),
> and the fact that this is using the mod_speedycgi frontend.
The version numbers are gathered at runtime, so for mod_speedycgi,
this would get picked up if you registered it in the Apache server
header that gets sent out. I'll list the test as mod_speedycgi.
> The fork/exec frontend will be much slower on hello-world so I don't
> want people to get the wrong idea. You may want to benchmark
> the fork/exec version as well.
>
If its slower than what's the point :) If mod_speedycgi is the faster
way to run it, they that should be good enough, no? If you would like
to contribute that test to the suite, please do so.
> - You may be able to eke out a little more performance by setting
> MaxRuns to 0 (infinite). The is set for mod_speedycgi using the
> SpeedyMaxRuns directive, or on the command-line using "-r0".
> This setting is similar to the MaxRequestsPerChild setting in apache.
>
Will do.
> - My tests show mod_perl/speedy much closer than yours do, even with
> MaxRuns at its default value of 500. Maybe you're running on
> a different OS than I am - I'm using Redhat 6.2. I'm also running
> one rev lower of mod_perl in case that matters.
>
I'm running the same thing, RH 6.2, I don't know if the mod_perl rev
matters, but what often does matter is that I have 2 CPUs in my box, so
my results often look different from other peoples.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
