in reply to Re^6: Should I just print my own HTTP headers?
in thread Should I just print my own HTTP headers?

If you had a million hits in one day... 1,000,000 / 24 =~ 41,666 per hour / 60 =~ 694 per minute = 11.5 per second. In my machine both of the options perform at over 6000 operations per second. In order for CGI to become my bottleneck then i would need 518,400,000 hits per day!!!! Yes this assumes a uniform distribution, but the numbers...look at them!! And this is on a PC not a web server and a single one, not a load balanced situation that you should have if you are approaching these kinds of hits. Is yours faster? Yes certainly, but CGI is a well worn tool, it will do what you need now, and down the road it will step up and do things you didn't even know you needed, not bite you in the arse like a hand built solution may.

Use what you want but don't make statments like 12471% more efficient like that is a reason to squeeze this particular piece of code.


___________
Eric Hodges
  • Comment on Re^7: Should I just print my own HTTP headers?

Replies are listed 'Best First'.
Re^8: Should I just print my own HTTP headers?
by Cap'n Steve (Friar) on Apr 07, 2007 at 06:25 UTC
    Your example is true if all you're doing is printing headers, and if you're on a dedicated server, and if you're not running a database server. The way I'm arranging this site, there will be one script that will probably be run at least 100 times more than any other. I'd rather be cautious and not get kicked off my host for using too many resources.

    Since know one seems to know of any situation where hand-crafted headers might be a problem, I'll just do that and I can switch to CGI later if I need to. The more complicated and less popular scripts can still use CGI.
[reply]

      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.


      ___________
      Eric Hodges
[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:

        <Reveal this spoiler or all spoilers in this node or all in this thread>

        100 concurrent users making 10 requests each

        <Reveal this spoiler>

        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]

In Section Seekers of Perl Wisdom