Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
laziness, impatience, and hubris
 
PerlMonks  

Re: What if mod_perl is not an option?

by matthewb (Curate)
on Feb 04, 2004 at 06:53 UTC ( [id://326473]=note: print w/replies, xml ) Need Help??

This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.


in reply to Re: What if mod_perl is not an option?
in thread 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.

MB

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.

Replies are listed 'Best First'.
Re: What if mod_perl is not an option?
by Abigail-II (Bishop) on Feb 04, 2004 at 07: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

      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?

        As long, as you have the resources keep the connection to the database open. Apache::DBI does that for you.
        Boris
        Or just saying that there should be as few (most likely one) database connection(s) per script instance?
        Yes.

        Abigail

Re: Re: Re: What if mod_perl is not an option?
by z3d (Scribe) on Feb 04, 2004 at 08: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."

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://326473]
help
Sections?
Information?
Find Nodes?
Leftovers?
    Notices?
    hippoepoptai's answer Re: how do I set a cookie and redirect was blessed by hippo!
    erzuuliAnonymous Monks are no longer allowed to use Super Search, due to an excessive use of this resource by robots.