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.

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.