[cgiapp] a question about FCGI

Ron Savage ron at savage.net.au
Sat Mar 6 18:01:13 EST 2010


Hi Puneet

On Sat, 2010-03-06 at 10:49 -0600, P Kishor wrote:
> http://cgi-app.org/index.cgi?FastCGI gives example code on how to use
> FCGI with CGI::App. Specifically,
> 
> use CGI::Fast();
> 
> while (my $q = new CGI::Fast){
>    my $app = new MyCGIApplication(QUERY => $q);   # this is your CGI::App module
>    $app->run();
> }
> 
> It is not clear to me where the above code goes. I have an instance
> script that uses C::A::Dispatch to launch the app. My App.pm has the
> usual cgiapp_init{} and cgiapp_get_query { return CGI::Simple->new();
> }. I have commented the latter because it seems CGI::Fast() comes with
> CGI, not with CGI::Simple. Now, where does the CGI::Fast invocation
> go?

There's a sample in the Synopsis for:
http://search.cpan.org/~rsavage/CGI-Application-Demo-Ajax-1.01/lib/CGI/Application/Demo/Ajax.pm

However, be warned, Alex Efros - author of FCGI::EV - has kindly been
giving me, via email, a background lecture in FCGI matters.

The fact is that I now accept I don't understand such things well enough
to use FCGI-style code, even though the given code works.

Hence I'm systematically replacing the FCGI demos I ship with
Plack-style equivalents.

Each module with demos still always ships with a classic CGI-style
script.

This means I do not offer the above code as an example of how to do
things, but only as an example of how I used to think things were
done :-).

As an aside: Alex points out that even if you're trying to develop
non-blocking code, your DBI calls will be blocking, unless you run the
db-accessing code in a separate process, and use non-blocking I/O to
send the results back to the CGI process. See how it's getting v-e-r-y
complex?

His group are developing a non-blocking interface to MySQL.

Of course, will very low-traffic web sites this is not a problem.

> Also, are there any benchmarks on comparing vanilla CGI::App, CGI::App
> with mod_perl, and CGI::App with FastCGI?

There are a few stats here, but not including FCGI:

http://search.cpan.org/~miyagawa/Starman-0.1001/lib/Starman.pm

Getting everything set up securely is naturally more important that pure
speed.

> Finally, I am assuming that CGI::Fast allows a persistent Perl process
> to run... and that, this Perl process is going to be the process that
> runs my application. Am I wrong in this assumption? What I am trying
> to ask is... will it be just the perl interpreter that will be
> persistent, and it will handle any and all web applications on my
> computer? (many apps with virtual hosts) OR will it be a perl process
> with all the modules relevant to each specific app, one process for
> each application?

These are precisely the questions I was asking, until I decided to go in
a different direction.

This is how Alex recommends using FCGI:

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

The docs clearly state that your app is managed and run independently of
Apache, but of course you have to configure Apache to use your app.

Anyway, since you app is running, it can load all modules needed, and
hence they are loaded once. But then it involves FastCgiWrapper and
security issues of some complexity. I decided to manage these issues in
a different way.

All,

Feel free to correct any misunderstandings I still have about these
matters.

-- 
Ron Savage
ron at savage.net.au
http://savage.net.au/index.html




More information about the cgiapp mailing list