Specifically I am thinking of this post.

Secondly all that that thread showed, even with the original numbers, is that you can do better on performance. But it does not compare, for instance, the cost of buying more machines versus having someone discover how to delete your customer database.

Now if you want to learn more about performance, go here. Those slides have extremely good advice about how to wind up being incredibly fast.

For the record, he uses CGI.pm.

Oh yes, I did. Infact, if you reread that specific post, you'll see what the benchmark (and I) are saying. Infact, let me repeat it:
• Perl script, with use Apache::Registry and use CGI.pm: 30 hits/sec
• PHP script, pure: 55 hits/sec
• Perl script, with only use Apache::Registry: 62 hits/sec
• Perl script, using only a dedicated Apache handler: 69 hits/sec
For the record, yes, but that's not my point.

--
&$WolfSkunks({use Perl;}); do {$you};

That's 2.59 million hits per day, on a K6-2, 400 mHz machine with 128 MB of RAM. Presumably, it's also a desktop machine.

I think you'll probably have more hardware to throw at the problem if you're consistently generating that kind of traffic.

I would rather spend my time learning how to write an Apache handler in Perl than trying to reinvent everything CGI.pm does. Of course, there's also CGI-Lite from the CPAN, in a pinch.

It is a question of what you prefer, spending time rewriting something that is already implemented (though not the fastest performer on the planet, it's been tested on millions in different programs by thousands of programmers), or figuring out the best way to configure your particular program, which will have to be written anyway.

I know which one I'll choose.

Duh, I shouldn't post in a hurry. I just glanced through that.

Have you looked at RE: RE: RE: big performance gain giving some CGI.pm performance tips from merlyn?

But in any case all that that post gave were performance numbers. There is also cost to consider. Having people write new code costs money. Having people audit that code costs money. Having someone find the hole you missed and delete your customer database costs a lot of money.

In the mean-time more boxes are cheap, in 18 months the processor will be twice as fast anyways, and you cannot predict where the performance bottlenecks will be. It is more important to have a sane architecture within which you can identify design mistakes and fix them than it is to squeeze performance out right away. Using off the shelf modules makes it easier to do that.