PERL CGI Beginners - Multiple .cgi scripts vs. one large script

Author

Multiple .cgi scripts vs. one large script

Hardly Armchair

2006-06-17, 7:56 am

Hello All,

I was wondering if it is more efficient (in terms of speed and processor
load) to have two different scripts of approximately the same size
called to handle two different functions, or to have one large script
handle all cgi functions using subroutines. Or perhaps these situations
are equivalent.

I apologize if I have just asked an unanswerable question.

Thanks,
Adam

George T. Moore

2006-06-17, 7:56 am

It depends on how you are using your scripts. The most "expensive"
aspect of the files is the IO used to read them from the hard drive they
reside on. If you are calling on the scripts multiple times and they
have to be read each time, rather than being cached in memory, then you
only want to read what is absolutely necessary. If one script always
calls another then you are probably better having the subroutines, which
would save IO.=20

-----Original Message-----
From: Hardly Armchair [mailto:nodice73@yahoo.com]=20
Sent: Wednesday, June 14, 2006 4:40 PM
To: beginners-cgi@perl.org
Subject: Multiple .cgi scripts vs. one large script

Hello All,

I was wondering if it is more efficient (in terms of speed and processor

load) to have two different scripts of approximately the same size=20
called to handle two different functions, or to have one large script=20
handle all cgi functions using subroutines. Or perhaps these situations

are equivalent.

I apologize if I have just asked an unanswerable question.

Thanks,
Adam

--=20
To unsubscribe, e-mail: beginners-cgi-unsubscribe@perl.org
For additional commands, e-mail: beginners-cgi-help@perl.org
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Sean Davis

2006-06-17, 7:56 am

Mr. Shawn H. Corey

2006-06-17, 7:56 am

On Wed, 2006-14-06 at 16:40 -0700, Hardly Armchair wrote:
> Hello All,
>
> I was wondering if it is more efficient (in terms of speed and processor
> load) to have two different scripts of approximately the same size
> called to handle two different functions, or to have one large script
> handle all cgi functions using subroutines. Or perhaps these situations
> are equivalent.

And what, exactly, do you mean by efficient?

Most definitions of efficient mean getting the maximum benefit from
available resources. So, does that mean the users have minimal response
time? Or does it mean your code maintainers can fix bugs easily? Or does
it mean your site has minimal cost on the internet?

Normally, compartizing your site would mean you can deal with only one
problem at a time, without worrying about its effects on the rest of the
site. But you would have to decide exactly what efficient really means.

--
__END__

Just my 0.00000002 million dollars worth,
--- Shawn

"For the things we have to learn before we can do them, we learn by doing them."
Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/

Adam Waite

2006-06-17, 7:56 am

Moore, George T. wrote:
> It depends on how you are using your scripts. The most "expensive"
> aspect of the files is the IO used to read them from the hard drive they
> reside on. If you are calling on the scripts multiple times and they
> have to be read each time, rather than being cached in memory, then you
> only want to read what is absolutely necessary. If one script always
> calls another then you are probably better having the subroutines, which
> would save IO.

I'll be more specific about my setup. I have two scripts running a
bulletin-board type thing. One of them is responsible for displaying
all of the posts at once, or just displaying one at a time. The other
script handles replying to posts or submitting new posts. I'd estimate
that the script responsible for looking at the posts gets used more
often, since more people look than actually say anything.

It would be easier to maintain this program if I made these two
functions subroutines of one larger script, and then called them using
some switch logic.

My main question then, is this. If a user visits the script, does the
server only load one instance of the program per visit, or does each
page change necessitate a new instance to begin? Because if only one
process is loaded per visit (for instance, the program is compiled once
and then used over and over while the user stays within pages covered by
that program), it makes more sense to combine them into one larger
program.

However, if the whole program must be loaded by the server each time the
user visits a new page (the program must be compiled and run for each
request) then it makes sense to only load what is necessary by splitting
up the script into several smaller ones.

As may be obvious by now, I do not know very much about how servers
handle requests for cgi programs, so I'm sorry if this question is posed
in a nonsensical way.

Thanks,
Adam

Ovid

2006-06-17, 7:56 am

Adam,

How your server is going to load things depends entirely upon the server and its configuration. CGI is slow, ISAPI is faster, mod_perl and FastCGI are faster still. Which one you're using and how you use it will dramatically change things. On the other
hand, if you only have a few thousand hits a day, it's probably not worth worrying about.

As programmers get more experienced, the learn one of the most important rules of programming: do NOT worry about performance unless you have an extremely good reason to do so. Build your systems to be correct and complete and only after you have a know
n performance issue should you worry about that. Even then, profile the system to find out what the issue is. For example, if it's your database connection or complicated SQL queries which are causing the problem, fiddling with nested foreach loops prob
ably isn't going to help that much.

The "don't worry about performance at first" concept is one that many programmers balk at, but once you adopt it, it makes life much, much easier.

Cheers,
Ovid

-- If this message is a response to a question on a mailing list, please send follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

----- Original Message ----
From: Adam Waite <nodice73@yahoo.com>
To: beginners-cgi@perl.org
Sent: Thursday, June 15, 2006 4:43:56 AM
Subject: Re: Multiple .cgi scripts vs. one large script

Moore, George T. wrote:
> It depends on how you are using your scripts. The most "expensive"
> aspect of the files is the IO used to read them from the hard drive they
> reside on. If you are calling on the scripts multiple times and they
> have to be read each time, rather than being cached in memory, then you
> only want to read what is absolutely necessary. If one script always
> calls another then you are probably better having the subroutines, which
> would save IO.

I'll be more specific about my setup. I have two scripts running a
bulletin-board type thing. One of them is responsible for displaying
all of the posts at once, or just displaying one at a time. The other
script handles replying to posts or submitting new posts. I'd estimate
that the script responsible for looking at the posts gets used more
often, since more people look than actually say anything.

It would be easier to maintain this program if I made these two
functions subroutines of one larger script, and then called them using
some switch logic.

My main question then, is this. If a user visits the script, does the
server only load one instance of the program per visit, or does each
page change necessitate a new instance to begin? Because if only one
process is loaded per visit (for instance, the program is compiled once
and then used over and over while the user stays within pages covered by
that program), it makes more sense to combine them into one larger
program.

However, if the whole program must be loaded by the server each time the
user visits a new page (the program must be compiled and run for each
request) then it makes sense to only load what is necessary by splitting
up the script into several smaller ones.

As may be obvious by now, I do not know very much about how servers
handle requests for cgi programs, so I'm sorry if this question is posed
in a nonsensical way.

Thanks,
Adam

--
To unsubscribe, e-mail: beginners-cgi-unsubscribe@perl.org
For additional commands, e-mail: beginners-cgi-help@perl.org
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Bill Stephenson

2006-06-17, 7:56 am

On Jun 14, 2006, at 6:40 PM, Hardly Armchair wrote:

> Hello All,
>
> I was wondering if it is more efficient (in terms of speed and
> processor load) to have two different scripts of approximately the
> same size called to handle two different functions, or to have one
> large script handle all cgi functions using subroutines. Or perhaps
> these situations are equivalent.

I asked a similar question a few months back ("How big is too big?").

After learning a lot from the responses and where they led me I started
looking more at CGI:: Application.

The general theory I get from this framework (as it applies to your
question) is that to help with management of subroutines you should
create scripts (modules) that hold subroutines that perform similar
tasks. No more than 10 subroutines in a script was the rule of thumb as
I recall.

Someone here mentioned that a Perl/CGI script that contains 1000 lines
is probably about as big as you'd want one to get. The script I'm
re-factoring to use CGI:: Application is now over 10,000 lines (with
comments). It still performs pretty well, but never sees huge amounts
of requests.

I completely agree with Ovid's comment, "do NOT worry about performance
unless you have an extremely good reason to do so." That's one reason
my script got so big. Performance still is not an issue for me, but
management is becoming one.

The "One big one versus many small ones" question seems best answered
by personal preference, up to a point. For me, management was getting
to be a pain.

Now I'd strongly recommend CGI:: Application to anyone working on a
perl/cgi app that will get bigger than that 1000 line max that was
previously suggested or needs features easily provided by the framework
and its plug-ins.

Kindest Regards,

--
Bill Stephenson
417-546-8390

Sponsored Links