Question on design for FastCGI

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 
}
[download]

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 ...	[reply]
Re^2: Question on design for FastCGI by Anonymous Monk on Oct 16, 2012 at 13:18 UTC
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?	[reply]
Re^3: Question on design for FastCGI by Anonymous Monk on Oct 17, 2012 at 00:48 UTC
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	[reply]
Re^4: Question on design for FastCGI by Anonymous Monk on Oct 17, 2012 at 16:04 UTC
Re^5: Question on design for FastCGI by Anonymous Monk on Oct 18, 2012 at 05:18 UTC
Some notes below your chosen depth have not been shown here
Re: Question on design for FastCGI by sundialsvc4 (Monsignor) 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.	[reply]


Keep It Simple, Stupid
	PerlMonks

Question on design for FastCGI

The best material for plates (tableware) is: