Vote with your money and find a hosting company that satisfies your needs.

Alas, often the developer will not have the luxury of this decision.

There are a bunch of optimisations that can be made even if mod_perl is not an option; here are some ideas off the top of my head:

• Streamline the design of your pages to be lightweight by relying on web standards and the bare minimum of images.
• Consider the architecture of your application to eliminate redundant database connections, repetitive processing etc.
• Think about generating static .html pages that are looked for first instead of dynamically outputting content on every request.

mod_perl rules and I am not suggesting for a minute that there is an equivalent substitute but you should view your situation as an opportunity to learn about tweaking the best performance out of the resources you have.

Update: amended `in the event that' to `even if' in my second paragraph following Abigail's (quite true) observation that my comments apply in the event that you do have mod_perl also.

There are a bunch of optimisations that can be made in the event that mod_perl is not an option;

Whether or not you are using these optimizations is orthonogal to whether you have mod_perl at your disposal or not. Lightweight pages are easier on both the server, the client, and the network in between regardless whether you use CGI or mod_perl. Eliminating redundant database connection is a good idea with both mod_perl and CGI. Static HTML is always faster, faster than mod_perl and faster than CGI.

Abigail

Eliminating redundant database connection is a good idea with both mod_perl and CGI.

Are you suggesting that there exists a method of keeping pooled database connections from within a CGI, non-mod_perl environment? Or just saying that there should be as few (most likely one) database connection(s) per script instance?

I just want to add my vote of reiteration on the eliminating redundant db connections. I once inherited a cgi app that took forever to load - looking at the source, I realized that part of the speed problem was that there were more than a dozen db based items, all of them run independantly of the other. And the infamous "works fine in development" didn't cut it - dev only had 3 users, vs a few hundred thousand a day in the real world.

---


"I have never written bad code. There are merely unanticipated features."