So you think my site is ugly? Customize it.

[ Home ] [ Up ] [ Feedback ] [ Contents ] [ Customize Look ]
[ Up ] [ Documentation ] [ Download ] [ Directives ]

How mod_fastcgi works : How FCGI_SA works

How mod_fastcgi Works

FastCgiServers

Mod_fastcgi works by starting a fastcgi server for each FastCgiServer directive.   Then, based on the "-processes n" configuration option, it starts n CGI applications, all listening to the same socket or port.  When an HTTP request for a FastCgiServer is made, the fastcgi server passes the request through the port or socket.   One of the CGI applications, listening on the port or socket, handles the request.   The CGI developer has no control over which CGI application handles the request.   It's kind of like calling customer support, and getting a different operator every time.

FastCgiExternalServers

FastCgiExternal servers work almost exactly the same as FastCgiServers,except that the developer or web admin is expected to start the CGI applications manually, and have them listening to the right port or socket. 

How FCGI_SA Works

Basics:

The key to FCGI_SA is the session server.  It handles controlling which CGI applications handle which clients, and it always redirects the client back to the same CGI application.  It may designate a CGI application as belonging exclusively to a client (not recommended), or it may allow a CGI application to be shared between clients. 

FastCgiServers:

FCGI_SA, the session affinity patch for mod_fastcgi, works by starting a session server for each FastCGIServer directive that contains a "-num_sessions n" configuration option.  Then, it starts a fastcgi server for each n sessions.  The session server makes sure that each fastcgi server only starts one CGI application.  The session server makes sure that a client is always redirected to the same fastcgi server, by tracking the client by IP address or cookie.  The fastcgi server handles the requests as in mod_fastcgi, but since each fastcgi server is only communicating with one CGI application, the request is guaranteed to be handled by the same CGI program.  

FastCgiExternalServers:

FastCgiExternalServers work about the same as FastCgiServers, except that the developer or web administrator is expected to start a CGI application for each session requested.   These CGI applications must be listening on consecutive ports.  For instance, if your directive was:

FastCgiExternalServer fastcgi-bin/test.pl -num_sessions 3 -host localhost:10000

Then three CGI applications would have to be started, listening on ports 10000 through 10002.

Exclusive vs. Shared Sessions:

When shared sessions are used (default), the session server hashes either the IP address or cookie presented by the client, and consistently selects a fastcgi server.   This means that the client will always be directed to the same CGI application, but it means that other clients will be directed there as well.  CGI applications still have to be written to distinguish between clients, and keep each client's session data separate.

When exclusive sessions are used, the session server keeps track of which fastcgi server belongs to each client, and allows only that client to access the fastcgi server (and thus, the CGI application).  The session server allows another client to take over the session after a timeout, or period of inactivity from the client.  The CGI application is not restarted after a timeout.  If a client attempts to start a new session, and there are no available sessions, the client will receive a server error message.  For the CGI developer, exclusive sessions means that the CGI application doesn't have to keep track of session data for each client simultaneously.  However, the application would have to reset its session data for each new client.

The problem with exclusive sessions is the amount of resources it takes to allow each client exclusive access to a CGI application.  If an application accepts 40 new sessions per second, and the average session length is 20 minutes, 48000 (40*60*20) CGI applications must be running on the server.  This is simply not feasible, or even possible, on most servers.  If the application takes a couple of new sessions per minute, 40 CGI applications may be feasible.  For this reason, exclusive sessions are not recommended, especially for busy servers.

Cookies vs. IP Addresses:

Because HTTP is a stateless protocol, there is no standard for keeping track of a client.  Some developers (like me) choose to use cookies because the use of subnets, gateways, and proxies throughout the Internet make IP addresses unreliable.  Some developers choose to use ip addresses, because cookies are not supported by some older browsers, and even on new browsers, some users disable cookies.  I choose to use cookies, because I feel that most clients will support cookies.  No matter which way you choose, however, you will run into problems with a small number of clients.  Be sure to warn your client that you are using cookies, or that proxies may not be supported (for ip addresses).  

[ Home ] [ Up ] [ Documentation ] [ Download ] [ Directives ]

Send mail to armbrust@tfarmbruster.com with questions or comments about this web site.
Last modified: October 7, 2000