[FASTCGI] FastCGI still a smart choice in 2010?

Rob rclemley at yahoo.com
Wed Apr 21 14:37:02 EDT 2010

On 04/21/2010 11:21 AM, Jean-Christophe Roux wrote:
> Are you using a C++ fastcgi library? Which one(s)?

We use an in-house c++ library wrapped around fcgiapp.h that's rather
dependent on other lower level libraries in our app.

Theres a "server" class which calls FCGX_Init() and then calls the
"loop" (or listener) class which calls FCGX_OpenSocket(), and then
loops, in each iteration creating one of our FastCGIRequest(socket)
objects, and then calling the request object's Accept() method.  If the
request object successfully accepts a connection, then the "loop" object
puts the "request" object on a queue object constructed using an STL
container  and boost::threads, boost::mutexes, and boost::conditions. 
There's a pool of "server threads" waiting for fastcgi requests to be
placed on the synchronized queue.   A "server thread" then retrieves a
request off the queue and responds to the client.  The server thread
sends all output back to the client through methods on the request object.

In this scheme, the "FastCGIRequest" object is the hub of activity and
data, along with the synchronized queue.

The class library was written circa 2004 according to the FastCGI spec
and has run largely unchanged since that time.

To accomplish this, the following functions are referenced from fcgiapp.h:

server object:

loop object:

fcgi request object:

On 04/21/2010 11:21 AM, Jean-Christophe Roux wrote:
> Hi Rob,
> Are you using a C++ fastcgi library? Which one(s)?
> Thanks
> ------------------------------------------------------------------------
> *From:* Rob <rclemley at yahoo.com>
> *To:* Gordon Colburn <gordon at group309.com>
> *Cc:* fastcgi-developers at mailman.pins.net
> *Sent:* Wed, April 21, 2010 10:42:44 AM
> *Subject:* Re: [FASTCGI] FastCGI still a smart choice in 2010?
> C++: Together with djb's daemontools, we have machines running
> hundreds of FastCgiExternalServers written in C++ connected via Unix
> Domain Sockets to a single apache2 instance.
> We can restart apache without disturbing the fastcgi backends and we
> can restart individual backends without disturbing apache or the other
> backends.
> With FastCGI, we could also run the FastCgiExternalServer backends on
> different machines if necessary.
> These tools are simple, modular and flexible.
> On 04/20/2010 09:06 PM, Gordon Colburn wrote:
>> There is not much reason to develop fastcgi Java applications as Java has a
>> number of very solid web technologies, the most basic of which is the
>> servlet spec. Servlets have been around for over 10 years, provide similar
>> functionality to fastcgi, are highly scalable, and are portable across
>> application servers. In fact, I'm not aware of anyone who is currently
>> developing Java fastcgi apps.
>> However, fastcgi is still commonly used to deploy PHP apps; on Apache,
>> fastcgi is arguably a more scalable technique for deploying PHP than is
>> mod_php. And, fastcgi is a great way to deploy C/C++ web applications, IMO.
>> Regards,
>> Gordon
>> -----Original Message-----
>> From: fastcgi-developers-bounces+gordon=group309.com at mailman.fastcgi.com
>> [mailto:fastcgi-developers-bounces+gordon=group309.com at mailman.fastcgi.com]
>> On Behalf Of Lyle
>> Sent: Tuesday, April 20, 2010 8:48 PM
>> To: Sven Svenson
>> Cc: fastcgi-developers at mailman.pins.net
>> Subject: Re: [FASTCGI] FastCGI still a smart choice in 2010?
>> Sven Svenson wrote:
>>> What's happened with the attitudes developers have about FastCGI? It
>>> seems that FastCGI is not the preferred way of deploying web
>>> applications outside the Perl world. Are the Java, PHP, Ruby and
>>> Python folks right to be using something other than FastCGI? Is
>>> FastCGI still around only because it is a legacy technology (Cobol is
>>> still around too!) or is FastCGI still a good choice for a high
>>> performance web site?
>> What do you think the other folks are recommending? As far as I've seen, 
>> if you want to have your software written in any of the above languages, 
>> fast and portable between different platforms and webservers, then 
>> FastCGI is still very much the way to go. (sorry for the long sentence)
>> Lyle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/attachments/20100421/20d20a45/attachment.html>

More information about the FastCGI-developers mailing list