Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Question on design for FastCGI

by Anonymous Monk
on Oct 15, 2012 at 15:12 UTC ( #999101=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

Reference: CGI or CGI::Fast (Thanks again for all the replies :)).

I've just begun to get a little hang of FastCGI via CGI::Fast. I wasn't used to persistence so the starting part was hard for me. I also found that my existing plain CGI code broke when I tried to convert some of it to run on FastCGI, as part of my exploration.

I've a little question at this toying stage and would like to seek your advice.

I'm wondering if it's better to have a FastCGI-aware main (dispatch) script that distributes the real work to modules, or have individual FastCGI-aware scripts that run independently?

Here's an outline of the two approaches:

Approach 1: Have a main script (e.g. main.fcgi) that distributes work +to modules #!/usr/local/bin/perl -T use Module1; use Module2; use Module3; code to initialise variables while (my $q = new CGI::Fast) { code to distribute job to Module1, Module2 or Module3 } Approach 2: Three FastCGI-aware scripts named module1.fcgi (functional +ly equivalent to Module1), module2.fcgi (functionally equivalent to M +odule2) and module3.fcgi (functionally equivalent to Module3). Each o +f these scripts have more or less the same structure: #!/usr/local/bin/perl -T code to initialise variables while (my $q = new CGI::Fast) { code to run }

Which of these is the better approach with respect to FastCGI?

Thanks for reading and I look forward to your replies!

Comment on Question on design for FastCGI
Download Code
Re: Question on design for FastCGI
by Anonymous Monk on Oct 15, 2012 at 15:54 UTC

    Which of these is the better approach with respect to FastCGI?

    It really doesn't matter all that much, you can even have independent fcgi scripts that use modules!

    Take perlmonks for example, index.pl does everything, but its really N-number of index.pl running on N-different machines -- its the same code, same module running from one script, for maximum maximum benefit from persistence (responsiveness)

    The reason we use modules is they make code-reuse and testing individual functions easy

    So which parts you choose to keep persistent depends on usage rates/patterns-- keep the most popular stuff persistent, keep response times low ...

      As I only have a beginning grasp of FastCGI, there are some concepts that I'm still grappling with.

      Let's say I go with Approach 1 with the modules imported before the start of the loop. Then later in loop, one of the subroutines in say, Module2, is called. Am I right to say that because the code in Modole2 persists between responses, calling the subroutine is faster than if it were plain CGI?

        Am I right to say that because the code in Modole2 persists between responses, calling the subroutine is faster than if it were plain CGI?

        Yes, its faster because the module is already loaded and ready to run, no time needs to be spent on loading it

        CGI starts a new process for each HTTP request, so program/modules/loaded, then program ended, memory freed

        This takes time. Compilation takes time, finding the modules, loading the modules, allocating memory ... freeing memory all take time.

        So for 1000 requests CGI takes , if it takes 1 second for program/modules to load/unload, and 1 second to run, that is half the time spent just loading/unloading the program, 2000 seconds total

        To a user of your website, this translates to a slow website. It doesn't matter if you and your users have super fast internet connections, if you're running a load balancing proxy... if your HTML is optimized to render quickly and your program is super fast, its always going to take at least 1 extra second for every single request

        With FastCGI, its 1001 seconds, 1000 seconds for 1000 HTTP requests, and 1 second to load the program/modules once

        To put another way, boy/girl-scouts/pioneers are taught not to walk with their knives or leave them laying around but to stow-away their knives (back into the sheath) when they're not cutting -- basically like CGI -- great for safety , acceptable when responsiveness isn't a priority

        But this wouldn't work for a chef, it would be way to slow. Which is why a chef has a work-space with a chopping block to leave his knife -- knife comes out of the sheath at start of day, and only goes back into sheath at the end of the day -- this is FastCGI

Re: Question on design for FastCGI
by sundialsvc4 (Abbot) on Oct 15, 2012 at 17:22 UTC

    Consider the approach taken by RPC::Any.   The request is quickly classified according to some criteria ... it could be part of the URL, part of the request, or some combination ... and a processing module for that kind of request is located, dynamically brought into memory if it’s not already there, and given the work.   It is a simple yet flexible design, and, best of all, it is already implemented by someone else.

    The FastCGI protocol is simple and flexible, and it can be applied in a lot of different ways.   I have used it among back-end service processes as well as front-end FastCGI worker bees.   Apache modules normally use a very simple strategy for apportioning out work among processes, but they don’t have to be simple strategies.

    As Anonymous said, you want to pay a lot of attention to the actual workloads that your site must deal with, and constantly observe as a basis for your fine-tuning.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://999101]
Approved by dorko
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (6)
As of 2014-12-22 10:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (116 votes), past polls