fcgi-perf.htm

来自「FastCGI,语言无关的、可伸缩架构的CGI开放扩展」· HTM 代码 · 共 457 行 · 第 1/2 页

      <P>
         Many Web server applications perform database access. Existing databases contain a lot of valuable
         information; Web server applications allow companies to give wider access to the information.
      </P>
      <P>
         Access to database management systems, even within a single machine, is via connection-oriented protocols. An
         application &quot;logs in&quot; to a database, creating a connection, then performs one or more accesses.
         Frequently, the cost of creating the database connection is several times the cost of accessing data over an
         established connection.
      </P>
      <P>
         To a first approximation database connections are just another type of state to be cached in memory by an
         application, so the discussion of caching above applies to caching database connections.
      </P>
      <P>
         But database connections are special in one respect: They are often the basis for database licensing. You pay
         the database vendor according to the number of concurrent connections the database system can sustain. A
         100-connection license costs much more than a 5-connection license. It follows that caching a database
         connection per Web server child process is not just wasteful of system&#39;s hardware resources, it could
         break your software budget.
      </P>
      <P>
      </P>
      <H3>
         <A NAME="S5">5. A Performance Test</A>
      </H3>
      <P>
         We designed a test application to illustrate performance issues. The application represents a class of
         applications that deliver personalized content. The test application is quite a bit simpler than any real
         application would be, but still illustrates the main performance issues. We implemented the application using
         both FastCGI and a current Web server API, and measured the performance of each.
      </P>
      <P>
      </P>
      <H4>
         <A NAME="S5.1">5.1 Application Scenario</A>
      </H4>
      <P>
         The application is based on a user database and a set of content files. When a user requests a content file,
         the application performs substitutions in the file using information from the user database. The application
         then returns the modified content to the user.
      </P>
      <P>
         Each request accomplishes the following:
      </P>
      <P>
      </P>
      <OL>
         <LI>
            authentication check: The user id is used to retrieve and check the password.
            <P>
            </P>
         </LI>
         <LI>
            attribute retrieval: The user id is used to retrieve all of the user&#39;s attribute values.
            <P>
            </P>
         </LI>
         <LI>
            file retrieval and filtering: The request identifies a content file. This file is read and all occurrences
            of variable names are replaced with the user&#39;s corresponding attribute values. The modified HTML is
            returned to the user.<BR>
            <BR>
         </LI>
      </OL>
      <P>
         Of course, it is fair game to perform caching to shortcut any of these steps.
      </P>
      <P>
         Each user&#39;s database record (including password and attribute values) is approximately 100 bytes long.
         Each content file is 3,000 bytes long. Both database and content files are stored on disks attached to the
         server platform.
      </P>
      <P>
         A typical user makes 10 file accesses with realistic think times (30-60 seconds) between accesses, then
         disappears for a long time.
      </P>
      <P>
      </P>
      <H4>
         <A NAME="S5.2">5.2 Application Design</A>
      </H4>
      <P>
         The FastCGI application maintains a cache of recently-accessed attribute values from the database. When the
         cache misses the application reads from the database. Because only a small number of FastCGI application
         processes are needed, each process opens a database connection on startup and keeps it open.
      </P>
      <P>
         The FastCGI application is configured as multiple application processes. This is desirable in order to get
         concurrent application processing during database reads and file reads. Requests are routed to these
         application processes using FastCGI session affinity keyed on the user id. This way all a user&#39;s requests
         after the first hit in the application&#39;s cache.
      </P>
      <P>
         The API application does not maintain a cache; the API application has no way to share the cache among its
         processes, so the cache hit rate would be too low to make caching pay. The API application opens and closes a
         database connection on every request; keeping database connections open between requests would result in an
         unrealistically large number of database connections open at the same time, and very low utilization of each
         connection.
      </P>
      <P>
      </P>
      <H4>
         <A NAME="S5.3">5.3 Test Conditions</A>
      </H4>
      <P>
         The test load is generated by 10 HTTP client processes. The processes represent disjoint sets of users. A
         process makes a request for a user, then a request for a different user, and so on until it is time for the
         first user to make another request.
      </P>
      <P>
         For simplicity the 10 client processes run on the same machine as the Web server. This avoids the possibility
         that a network bottleneck will obscure the test results. The database system also runs on this machine, as
         specified in the application scenario.
      </P>
      <P>
         Response time is not an issue under the test conditions. We just measure throughput.
      </P>
      <P>
         The API Web server is in these tests is Netscape 1.1.
      </P>
      <P>
      </P>
      <H4>
         <A NAME="S5.4">5.4 Test Results and Discussion</A>
      </H4>
      <P>
         Here are the test results:
      </P>
      <P>
      </P>
      <DIV CLASS="c3">
<PRE>
    FastCGI  12.0 msec per request = 83 requests per second
    API      36.6 msec per request = 27 requests per second
</PRE>
      </DIV>
      <P>
         Given the big architectural advantage that the FastCGI application enjoys over the API application, it is not
         surprising that the FastCGI application runs a lot faster. To gain a deeper understanding of these results we
         measured two more conditions:
      </P>
      <P>
      </P>
      <UL>
         <LI>
            API with sustained database connections. If you could afford the extra licensing cost, how much faster
            would your API application run?
            <P>
            </P>
<PRE>
    API      16.0 msec per request = 61 requests per second
</PRE>
            Answer: Still not as fast as the FastCGI application.
            <P>
            </P>
         </LI>
         <LI>
            FastCGI with cache disabled. How much benefit does the FastCGI application get from its cache?
            <P>
            </P>
<PRE>
    FastCGI  20.1 msec per request = 50 requests per second
</PRE>
            Answer: A very substantial benefit, even though the database access is quite simple.<BR>
            <BR>
         </LI>
      </UL>
      <P>
         What these two extra experiments show is that if the API and FastCGI applications are implemented in exactly
         the same way -- caching database connections but not caching user profile data -- the API application is
         slightly faster. This is what you&#39;d expect, since the FastCGI application has to pay the cost of
         inter-process communication not present in the API application.
      </P>
      <P>
         In the real world the two applications would not be implemented in the same way. FastCGI&#39;s architectural
         advantage results in much higher performance -- a factor of 3 in this test. With a remote database or more
         expensive database access the factor would be higher. With more substantial processing of the content files
         the factor would be smaller.
      </P>
      <P>
      </P>
      <H3>
         <A NAME="S6">6. Multi-threaded APIs</A>
      </H3>
      <P>
         Web servers with a multi-threaded internal structure (and APIs to match) are now starting to become more
         common. These servers don&#39;t have all of the disadvantages described in Section 3. Does this mean that
         FastCGI&#39;s performance advantages will disappear?
      </P>
      <P>
         A superficial analysis says yes. An API-based application in a single-process, multi-threaded server can
         maintain caches and database connections the same way a FastCGI application can. The API-based application
         does not pay for inter-process communication, so the API-based application will be slightly faster than the
         FastCGI application.
      </P>
      <P>
         A deeper analysis says no. Multi-threaded programming is complex, because concurrency makes programs much more
         difficult to test and debug. In the case of multi-threaded programming to Web server APIs, the normal problems
         with multi-threading are compounded by the lack of isolation between different applications and between the
         applications and the Web server. With FastCGI you can write programs in the familiar single-threaded style,
         get all the reliability and maintainability of process isolation, and still get very high performance. If you
         truly need multi-threading, you can write multi-threaded FastCGI and still isolate your multi-threaded
         application from other applications and from the server. In short, multi-threading makes Web server APIs
         unusable for practially all applications, reducing the choice to FastCGI versus CGI. The performance winner in
         that contest is obviously FastCGI.
      </P>
      <P>
      </P>
      <H3>
         <A NAME="S7">7. Conclusion</A>
      </H3>
      <P>
         Just how fast is FastCGI? The answer: very fast indeed. Not because it has some specially-greased path through
         the operating system, but because its design is well matched to the needs of most applications. We invite you
         to make FastCGI the fast, open foundation for your Web server applications.
      </P>
      <P>
      </P>
      <HR>
      <A HREF="http://www.openmarket.com/"><IMG SRC="omi-logo.gif" ALT="OMI Home Page"></A> 
      <ADDRESS>
         &copy; 1995, Open Market, Inc. / [e-mail]
      </ADDRESS>
   </BODY>
</HTML>