fcgi-perf.htm
来自「FastCGI,语言无关的、可伸缩架构的CGI开放扩展」· HTM 代码 · 共 457 行 · 第 1/2 页
HTM
457 行
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML> <HEAD> <TITLE> Understanding FastCGI Application Performance </TITLE><STYLE TYPE="text/css"> body { background-color: #FFFFFF; color: #000000; } :link { color: #cc0000 } :visited { color: #555555 } :active { color: #000011 } div.c3 {margin-left: 2em} h5.c2 {text-align: center} div.c1 {text-align: center}</STYLE> </HEAD> <BODY> <DIV CLASS="c1"> <A HREF="http://fastcgi.com"><IMG BORDER="0" SRC="../images/fcgi-hd.gif" ALT="[[FastCGI]]"></A> </DIV> <BR CLEAR="all"> <DIV CLASS="c1"> <H3> Understanding FastCGI Application Performance </H3> </DIV> <!--Copyright (c) 1996 Open Market, Inc. --> <!--See the file "LICENSE.TERMS" for information on usage and redistribution--> <!--of this file, and for a DISCLAIMER OF ALL WARRANTIES. --> <DIV CLASS="c1"> Mark R. Brown<BR> Open Market, Inc.<BR> <P> 10 June 1996<BR> </P> </DIV> <P> </P> <H5 CLASS="c2"> Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.<BR> Tel: 617-621-9500 Fax: 617-621-1703 URL: <A HREF= "http://www.openmarket.com/">http://www.openmarket.com/</A><BR> $Id: fcgi-perf.htm,v 1.4 2002/02/25 00:42:59 robs Exp $<BR> </H5> <HR> <UL TYPE="square"> <LI> <A HREF="#S1">1. Introduction</A> </LI> <LI> <A HREF="#S2">2. Performance Basics</A> </LI> <LI> <A HREF="#S3">3. Caching</A> </LI> <LI> <A HREF="#S4">4. Database Access</A> </LI> <LI> <A HREF="#S5">5. A Performance Test</A> <UL TYPE="square"> <LI> <A HREF="#S5.1">5.1 Application Scenario</A> </LI> <LI> <A HREF="#S5.2">5.2 Application Design</A> </LI> <LI> <A HREF="#S5.3">5.3 Test Conditions</A> </LI> <LI> <A HREF="#S5.4">5.4 Test Results and Discussion</A> </LI> </UL> </LI> <LI> <A HREF="#S6">6. Multi-threaded APIs</A> </LI> <LI> <A HREF="#S7">7. Conclusion</A> </LI> </UL> <P> </P> <HR> <H3> <A NAME="S1">1. Introduction</A> </H3> <P> Just how fast is FastCGI? How does the performance of a FastCGI application compare with the performance of the same application implemented using a Web server API? </P> <P> Of course, the answer is that it depends upon the application. A more complete answer is that FastCGI often wins by a significant margin, and seldom loses by very much. </P> <P> Papers on computer system performance can be laden with complex graphs showing how this varies with that. Seldom do the graphs shed much light on <I>why</I> one system is faster than another. Advertising copy is often even less informative. An ad from one large Web server vendor says that its server "executes web applications up to five times faster than all other servers," but the ad gives little clue where the number "five" came from. </P> <P> This paper is meant to convey an understanding of the primary factors that influence the performance of Web server applications and to show that architectural differences between FastCGI and server APIs often give an "unfair" performance advantage to FastCGI applications. We run a test that shows a FastCGI application running three times faster than the corresponding Web server API application. Under different conditions this factor might be larger or smaller. We show you what you'd need to measure to figure that out for the situation you face, rather than just saying "we're three times faster" and moving on. </P> <P> This paper makes no attempt to prove that FastCGI is better than Web server APIs for every application. Web server APIs enable lightweight protocol extensions, such as Open Market's SecureLink extension, to be added to Web servers, as well as allowing other forms of server customization. But APIs are not well matched to mainstream applications such as personalized content or access to corporate databases, because of API drawbacks including high complexity, low security, and limited scalability. FastCGI shines when used for the vast majority of Web applications. </P> <P> </P> <H3> <A NAME="S2">2. Performance Basics</A> </H3> <P> Since this paper is about performance we need to be clear on what "performance" is. </P> <P> The standard way to measure performance in a request-response system like the Web is to measure peak request throughput subject to a response time constriaint. For instance, a Web server application might be capable of performing 20 requests per second while responding to 90% of the requests in less than 2 seconds. </P> <P> Response time is a thorny thing to measure on the Web because client communications links to the Internet have widely varying bandwidth. If the client is slow to read the server's response, response time at both the client and the server will go up, and there's nothing the server can do about it. For the purposes of making repeatable measurements the client should have a high-bandwidth communications link to the server. </P> <P> [Footnote: When designing a Web server application that will be accessed over slow (e.g. 14.4 or even 28.8 kilobit/second modem) channels, pay attention to the simultaneous connections bottleneck. Some servers are limited by design to only 100 or 200 simultaneous connections. If your application sends 50 kilobytes of data to a typical client that can read 2 kilobytes per second, then a request takes 25 seconds to complete. If your server is limited to 100 simultaneous connections, throughput is limited to just 4 requests per second.] </P> <P> Response time is seldom an issue when load is light, but response times rise quickly as the system approaches a bottleneck on some limited resource. The three resources that typical systems run out of are network I/O, disk I/O, and processor time. If short response time is a goal, it is a good idea to stay at or below 50% load on each of these resources. For instance, if your disk subsystem is capable of delivering 200 I/Os per second, then try to run your application at 100 I/Os per second to avoid having the disk subsystem contribute to slow response times. Through careful management it is possible to succeed in running closer to the edge, but careful management is both difficult and expensive so few systems get it. </P> <P> If a Web server application is local to the Web server machine, then its internal design has no impact on network I/O. Application design can have a big impact on usage of disk I/O and processor time. </P> <P> </P> <H3> <A NAME="S3">3. Caching</A> </H3> <P> It is a rare Web server application that doesn't run fast when all the information it needs is available in its memory. And if the application doesn't run fast under those conditions, the possible solutions are evident: Tune the processor-hungry parts of the application, install a faster processor, or change the application's functional specification so it doesn't need to do so much work. </P> <P> The way to make information available in memory is by caching. A cache is an in-memory data structure that contains information that's been read from its permanent home on disk. When the application needs information, it consults the cache, and uses the information if it is there. Otherwise is reads the information from disk and places a copy in the cache. If the cache is full, the application discards some old information before adding the new. When the application needs to change cached information, it changes both the cache entry and the information on disk. That way, if the application crashes, no information is lost; the application just runs more slowly for awhile after restarting, because the cache doesn't improve performance when it is empty. </P> <P> Caching can reduce both disk I/O and processor time, because reading information from disk uses more processor time than reading it from the cache. Because caching addresses both of the potential bottlenecks, it is the focal point of high-performance Web server application design. CGI applications couldn't perform in-memory caching, because they exited after processing just one request. Web server APIs promised to solve this problem. But how effective is the solution? </P> <P> Today's most widely deployed Web server APIs are based on a pool-of-processes server model. The Web server consists of a parent process and a pool of child processes. Processes do not share memory. An incoming request is assigned to an idle child at random. The child runs the request to completion before accepting a new request. A typical server has 32 child processes, a large server has 100 or 200. </P> <P> In-memory caching works very poorly in this server model because processes do not share memory and incoming requests are assigned to processes at random. For instance, to keep a frequently-used file available in memory the server must keep a file copy per child, which wastes memory. When the file is modified all the children need to be notified, which is complex (the APIs don't provide a way to do it). </P> <P> FastCGI is designed to allow effective in-memory caching. Requests are routed from any child process to a FastCGI application server. The FastCGI application process maintains an in-memory cache. </P> <P> In some cases a single FastCGI application server won't provide enough performance. FastCGI provides two solutions: session affinity and multi-threading. </P> <P> With session affinity you run a pool of application processes and the Web server routes requests to individual processes based on any information contained in the request. For instance, the server can route according to the area of content that's been requested, or according to the user. The user might be identified by an application-specific session identifier, by the user ID contained in an Open Market Secure Link ticket, by the Basic Authentication user name, or whatever. Each process maintains its own cache, and session affinity ensures that each incoming request has access to the cache that will speed up processing the most. </P> <P> With multi-threading you run an application process that is designed to handle several requests at the same time. The threads handling concurrent requests share process memory, so they all have access to the same cache. Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- but with FastCGI you can write single threaded <I>or</I> multithreaded applications. </P> <P> </P> <H3> <A NAME="S4">4. Database Access</A> </H3>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?