Yes my numbers are only true in that case but it is all relative. The point wasn't the number, they where the wow, the point was that both take an exceptionaly small amount of time, so don't base any judgments on a benchmark figure that is "relativly" worthless. Sorry if i missed that point before.
| [reply] |
Just for grins, I thought I'd have a go a seeing how the benchmark figures, as well as the extrapolations from them, stood up to a "real world" test. The following shows a the results of hitting the same, lightweight preforking server serving similar dynamic pages via CGI.pm, or a simplistic, 'raw cgi' script:
10 concurrent users making 100 requests each:
100 concurrent users making 10 requests each
The signifciance of these numbers? Probably very little as the users were running in the same box as the server and networking effects are eliminated, but it may serve to show that whilst the relativistic headline percentages produced by Benchmark serve to inflate differences, so extrapolations of the wallclock timings are equally flawed.
The only difference between the raw and cgi tests is the loading and use of the CGI.pm module. Whilst with 10 concurrent users the 3x difference in the delivery time, from ~250ms to ~850ms (excluding network latency), is neither here nor there. Once you get 100 users concurrent, the increase from ~3 seconds to ~9 seconds (exclusive) is likely to begin to impact the users perceptions of the website.
Is this significant enough to consider hand rolling CGIs with the risks that entails? Probably not. But it might be enough to consider looking elsewhere than CGI.pm, say CGI::Simple?
I'll make my test scripts available to anyone who's set up to run the tests under more real world conditions
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |