Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

CGI::Fast / Apache - Strange behaviour?

by DreamT (Pilgrim)
on Aug 16, 2012 at 10:23 UTC ( #987730=perlquestion: print w/ replies, xml ) Need Help??
DreamT has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
Consider the following code:
# Doing some stuff # .... use CGI::Fast while ($query = new CGI::Fast) { # Doing some stuff # ..... # Calling a subroutine that doesn't exist, in some cases (if $a_condition == 1) { &Undefined_Subroutine(); } } ...
The code above will of course throw an error since we're calling a subroutine that doesn't exist. But, I think that I may have spotted a behaviour that doen't make sense. It seems like one ore more Apache processes are spawned when this happens, which in some cases leads to performance degradation for everyone that uses this script when it happens (consider that a lot of calls are made to the script that produces the same error).

My questions are:
1. Do you think that this behaviour exists, i.e. that a crashing script creates a performance degradation caused by many concurring Apache instances of the script?
2. If so, could we add/change something to avoid it? Removing the erroneous code (or eval'ing it) is a solution of course, I'm rather thinking of the behaviour itself, as a fallback.
3. Do you have any other FastCGI "tweaks" that you'd like to share?

Comment on CGI::Fast / Apache - Strange behaviour?
Download Code
Re: CGI::Fast / Apache - Strange behaviour?
by sundialsvc4 (Abbot) on Aug 16, 2012 at 12:21 UTC

    This behavior isn’t “strange” ... I think you hit the nail on the head as to its cause and the general remedy.   I have not yet personally used CGI::Fast, preferring instead to use Plack, but it does indeed appear to me that your FastCGI processes are crashing, after which they are necessarily being re-spawned.   A completely unhandled exception will cause any script to die, so this outcome must be prevented, because the causes of exceptions in production code cannot.   I think that the entirely-correct strategy is to wrap the body of that while loop inside of an exception-handling block, e.g. eval, so that any exception, no matter what the cause, will be explicitly trapped and some traceback given in a log.   (You may have to write code to do this.)   I am frankly puzzled why the examples for CGI::Fast do not include some kind of exception handling.   In general, the synopsis given seems simplistic, although I’m sure the code works well.

    As I said, I customarily use include Plack, and, unrelated to that, part of the standard preamble for my modules is this:

    use Try::Tiny;
    use Exception::Class;
    use Exception::Caught;
    use except::classes; // a set of app-specific exception classes
    use Error::Return;

    You may wish to peruse some of these.   HTH...

      Thank you for your input on this, valuable indeed! I will do some testning, and will maybe also have a look at Plack. Thanks!
Re: CGI::Fast / Apache - Strange behaviour?
by CountZero (Bishop) on Aug 16, 2012 at 16:06 UTC
    A program that crashes, especially in a mod_perl or FastCGI environment can cause all kinds of unexpected mayhem and sometimes the effects to "contain" the damage may even be worse or increase the damage. By its very nature a "crash" is uncontrolled and it is anybody's guess what will be its ill effects. It is not always possible to fully clean-up a crash: unreachable memory, zombie processes or runaway processes may remain at large despite our best efforts.

    Many years ago (I think it was in one of the Apache 1 versions), there was even an option to bring down the whole server at regular intervals and "reboot" it, just to clean up all accumulated junk and even now there is still a possibility to kill individual Apache worker processes after a certain number of uses.

    The windows OS was particularly prone to it, but regularly doing "reboots" during quiet times seemed to avoid the worst effects. The only problem was trying to sell this "solution" to the head of IT as a "feature" rather than a kludge to deal with badly written software.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics

      To clarify ...

      Within my “persistent programs” of any sort, the outer level request handler contains an all-encompassing “exception handler of last resort,” and it carefully examines just what sort of exception has been thrown.

      That is the reason why I use exception classes, which are objects.   (Yes, you can die with an object, as well as with a string.)   Code that cannot succeed throws an exception of a particular class.   (If it invokes code that might not use these classes, it “wraps” that code in an inner exception-handler which throws an exception-class containing among other things the text.)   Some exceptions are used as a way to gracefully bail-out from anywhere.   Others truly represent detected program flaws.   The outer-level handler will catch that fly-ball if nobody else does, and will do something appropriate.

      It is true that any exception can leave various kinds of “smoking remains” which can accumulate; especially memory.   It happens often enough that Plack, for instance, has a so-called “hara kiri” facility which causes the workers to periodically die-off.   Sometimes the appropriate response to a certain exception is to die-off immediately.   But the outer level handler still has to capture the error traceback (another feature of these exception classes) and to sound the alarm somewhere.

      Absolutely the worst thing that can happen is an exception that causes incomplete output and that is not correctly trapped or logged as an exception.   We have all seen web sites and so-forth that have done this.   Usually the output just stops in m

      ;-)

Re: CGI::Fast / Apache - Strange behaviour?
by stonecolddevin (Vicar) on Aug 16, 2012 at 16:30 UTC

    Somewhat of a tangent to your original question but please check out Plack. It will make your life much much easier in the short and long run.

    Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://987730]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (10)
As of 2014-10-02 17:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (67 votes), past polls