Re: To get rid of database connection with each CGI call ...

Bob Ramstad (
Thu, 6 Mar 1997 08:48:35 -0500 (EST)

Date: Thu, 6 Mar 1997 08:48:35 -0500 (EST)
Message-Id: <>
From: Bob Ramstad <>
In-Reply-To: <97Mar5.173639pst."86028"> (message from
Subject: Re: To get rid of database connection with each CGI call ...

we've done both.  the nice thing about having a separate database
"daemon" is that you've got complete control over how it is started,
how it is stopped, what signals it listens to and so forth.  it is
also nice from the "building block" perspective i.e. if the underlying
database changed only the daemon would need to change, the actual
application would stay exactly the same.

that said, the nice thing about the FastCGI approach is that the
entire process stays in memory so if you've got complex CGI stuff
going on all of that code stays memory resident.  another nice thing
is that FastCGI can easily run multiple copies of the process --
writing a database "daemon" which has mutiple children is a bit more
complicated (especially to test) than one which is single threaded.

either method can be used to get rid of the database open and close.
in our testing, we've seen a fivefold improvement in latency (i.e. it
takes the application one fifth the time to execute) and a tenfold+
improvement in throughput (i.e. it takes the server one tenth the time
to begin answering the request) given a reasonable number of FastCGI

-- Bob

         _/      _/  _/_/_/_/  _/  _/_/_/_/                  
        _/_/    _/  _/        _/  _/                         
       _/  _/  _/  _/_/_/    _/  _/                          
      _/    _/_/  _/        _/  _/                           
     _/      _/  _/        _/  _/_/_/_/                      
New    Frontiers    Information    Corporation
222 3rd Street, Suite 0174, Cambridge MA 02142
phone: (617) 497-6811      fax: (617) 441-9265