Re: What if mod_perl is not an option?

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.

Comment on Re: What if mod_perl is not an option?

Replies are listed 'Best First'.
Re: What if mod_perl is not an option? by Abigail-II (Bishop) on Feb 04, 2004 at 12:23 UTC
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	[reply]
Re: What if mod_perl is not an option? by Coruscate (Sexton) on Feb 04, 2004 at 21:54 UTC
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?	[reply]
Re: What if mod_perl is not an option? by Abigail-II (Bishop) on Feb 04, 2004 at 22:22 UTC
Or just saying that there should be as few (most likely one) database connection(s) per script instance? Yes. Abigail	[reply]
Re: Re: What if mod_perl is not an option? by borisz (Canon) on Feb 04, 2004 at 22:06 UTC
As long, as you have the resources keep the connection to the database open. Apache::DBI does that for you. Boris	[reply]
Re: Re: Re: What if mod_perl is not an option? by z3d (Scribe) on Feb 04, 2004 at 13:37 UTC
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."	[reply]