Mark Brown (
Wed, 03 Jul 1996 12:32:25 -0400

Message-Id: <>
Subject: Re: FAST CGI - 
In-Reply-To: Your message of "02 Jul 1996 09:33:40 EST."
Date: Wed, 03 Jul 1996 12:32:25 -0400
From: Mark Brown <>

Patrick Walsh writes:

    We are doing stress testing of our FCGI system.  We have 100
    simultaneous browser sessions running from a testing utility
    against two (2) FCGI processes (non Server managed).  We
    consistently get the following error:

        [Tue Jul  2 09:16:39 1996] httpd: (#252) error connecting to 
        FastCGI server, can't connect to FastCGI process (Connection refused)
        [Tue Jul  2 09:16:39 1996] httpd: access to /x/DA denied for, reason: (#230) error connecting to FastCGI
        server, can't connect to FastCGI process:  (Resource temporarily

    What is causing this error?  Do we need to have more FCGI server
    processes?  Is there a configuration parameter, like a retry count?

These error messages mean that the Web server was unable to connect
to the FastCGI application.  There is plenty of error recovery within
the operating system so there is nothing to be gained from a
higher-level retry.

There are two things to do:

   1) Increase the number of FastCGI server processes.  Doing this
      will increase system throughput if the FastCGI server processes
      are blocking to do I/O, which they most likely are.

      If the normal path through your FastCGI server process spends
      X msec computing and m*X msec waiting for I/O, then you'd
      want to configure m+1 FastCGI server processes per CPU.
      (This would be a starting point for fine-tuning; I/O 
      interference could cause you to reduce the number of
      FastCGI server processes.)

      A simple tool like strace can give you a pretty good idea of
      how much time your application spends waiting for I/O.

   2) Increase the listen queue depth.  The listen queue is where
      connections from the Web server to the FastCGI application
      class wait to be accepted by some process in the class.
      If the listen queue is full when a new connection arrives,
      that connection is refused immediately.

      For your test, a listen queue depth of 100 would be enough,
      since you have at most 100 concurrent requests.

      In a production system a long listen queue does not increase
      throughput or reduce response time, but it does smooth out
      transient variations in the offered load or in the application's
      response time.

      Unfortunately, cgi-fcgi compiles in the value 5 for the listen
      queue depth.  You can change the line in cgi-fcgi.c:

            || listen(FCGI_LISTENSOCK_FILENO, 5) < 0) {

      replacing 5 with 100 or whatever you need.

I hope this helps.