recently-asked FastCGI questions

Mark Brown (mbrown@OpenMarket.com)
Wed, 01 May 1996 18:31:43 -0400

Message-Id: <199605012231.SAA12326@breckenridge.openmarket.com>
To: fcgi-developers@OpenMarket.com
Subject: recently-asked FastCGI questions
Date: Wed, 01 May 1996 18:31:43 -0400
From: Mark Brown <mbrown@OpenMarket.com>


I've been getting a lot of questions lately by phone and via
direct email.  I thought I should summarize some of the questions
and answers for the group.  At some point I hope we'll have a FAQ.

Some of the answers below are *not* true for the beta OMI WebServer
2.0, due to bugs.  They are all true, to the best of my knowledge,
for the GA OMI WebServer 2.0.


Q: Have you built a FastCGI sybperl binary?

A: Nope, we haven't done that.  We'd be happy to distribute
such binaries from www.fastcgi.com if someone else will build them.


Q: What's faster, FastCGI Filters or Server-Side Includes?

A: That depends.  SSI is very fast if you don't run any
applications (i.e. just access server variables).  Most
SSIs do run applications.  SSI and FastCGI are a great
combination.

If an SSI runs a single FastCGI Responder,
that may be faster than doing the same job with a FastCGI Filter.
If an SSI runs multiple FastCGI Responders to fill in various
parts of the document, that could easily be slower due to start-up
overheads per request.  If performance is crucial you may have
to prototype both ways and measure.


Q: I tried running my existing CGI application as FastCGI and it
didn't work.  What gives?

A: You need to recompile and relink the application, and you
need to put in an Accept loop.  Having done this your application
will run as both CGI and FastCGI.  But unmodified CGI apps
won't work as FastCGI apps.


Q: Can I use cgi-fcgi to run remote applications with a
non-OMI server?

A: Sure.  First log into the remote host and start the remote
application using

    % cgi-fcgi -bind -connect localhost:5678 my_app

(choose your own port instead of 5678, your own app name
instead of my_app).  Then return to the Web server host and
direct a request to a cgi of the form

   #! cgi-fcgi -f
   -bind -connect margaret:5678

if the remote host is named margaret.  This will connect to
the application you started and run one request.  The cgi-fcgi
program will exit like any CGI program, but the remote application
will keep running.


Q: Why would I want to run more than one FastCGI process on a single
listening socket?

A: First, why would you want to run more than one at all?  Basically
you'd do this to get concurrency.  With a single-threaded application,
the application blocks while doing I/O, and can't take advantage of
multiple processors.  So you configure several processes to get more
throughput and shorter response times when the application does I/O
or runs on a multiprocessor.  If the application does no I/O and
runs on a uniprocessor, there is *no* advantage to running more than
a single process.

You'd have the processes share a single listening socket to allow them to
do efficient load balancing.  (This technique is not available on AIX.)

In many cases you get even higher performance using session affinity,
because of the application-level caching it enables.  With session
affinity only on process listens per socket.


Q: Can two *different* applications share the same listening socket?

A: This isn't a good idea, because the Web server won't be able
to direct requests to the specific application in this case.
The results of such a configuration are not predictable.


Q: Can I use variable bindings created by an Authorizer
from my OMI server config?

A: Yes.  This means, for instance, that you can use an
Authorizer to compute a session affinity key, then pass
that key to the AffinityMap Region command.


Q: Can I use variable bindings created by an Authorizer
from a later Authorizer?

A: Yes.  This means, for instance, that you can perform
authentication in one Authorizer and access control
in another.


    --mark