📄 asgxc.htm
字号:
<HTML>
<HEAD>
<TITLE>Apache Server Survival Guide asgxc.htm </TITLE>
<LINK REL="ToC" HREF="index.htm" tppabs="http://docs.rinet.ru:8080/Apachu/index.htm">
<LINK REL="Index" HREF="htindex.htm" tppabs="http://docs.rinet.ru:8080/Apachu/htindex.htm">
<LINK REL="Next" HREF="asgxd.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgxd.htm">
<LINK REL="Previous" HREF="asgxb.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgxb.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080">
<!--#exec cmd="/www/docs/ssi-bin/restricted_search.ssi"-->
<!--#exec cmd="/www/docs/ssi-bin/inc.ssi"-->
<A NAME="I0"></A>
<H2>Apache Server Survival Guide asgxc.htm</H2>
<P ALIGN=LEFT>
<A HREF="asgxb.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgxb.htm" TARGET="_self"><IMG SRC="purprev.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="index.htm" tppabs="http://docs.rinet.ru:8080/Apachu/index.htm" TARGET="_self"><IMG SRC="purtoc.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purtoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="asgxd.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgxd.htm" TARGET="_self"><IMG SRC="purnext.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purnext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>
<HR ALIGN=CENTER>
<P>
<UL>
<UL>
<UL>
<LI>
<A HREF="#E68E183" >FastCGI Features</A>
<LI>
<A HREF="#E68E184" >Performance Enhancement</A>
<LI>
<A HREF="#E68E185" >FastCGI API</A>
<LI>
<A HREF="#E68E186" >What a FastCGI Application Looks Like</A>
<UL>
<LI>
<A HREF="#E69E212" >FastCGI and C</A>
<LI>
<A HREF="#E69E213" >FastCGI with Perl and Tcl</A></UL>
<LI>
<A HREF="#E68E187" >Installing and Configuring FastCGI</A>
<UL>
<LI>
<A HREF="#E69E214" >Incorporating FastCGI Functionality into Apache</A>
<LI>
<A HREF="#E69E215" >cgi-fcgi</A></UL>
<LI>
<A HREF="#E68E188" >Building the FastCGI Developer's Kit</A>
<LI>
<A HREF="#E68E189" >Making Perl Fly</A>
<UL>
<LI>
<A HREF="#E69E216" >Perl FastCGI Programs</A></UL>
<LI>
<A HREF="#E68E190" >The mod_fastcgi Module</A>
<UL>
<LI>
<A HREF="#E69E217" >The AppClass Directive</A>
<LI>
<A HREF="#E69E218" >Example</A></UL>
<LI>
<A HREF="#E68E191" >Summary</A></UL></UL></UL>
<HR ALIGN=CENTER>
<A NAME="E66E19"></A>
<H1 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>C</B></FONT></CENTER></H1>
<BR>
<A NAME="E67E26"></A>
<H2 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>FastCGI</B></FONT></CENTER></H2>
<BR>
<P>FastCGI is a high-performance replacement to the CGI standard. It provides a significant improvement in performance over the existing CGI interface. In its current implementation, FastCGI provides many desirable enhancements that make it a very attractive and competitive alternative to proprietary technologies for developing Web-based applications. Under many circumstances, it will be a better choice to implement FastCGI than to develop a custom server module using Apache's proprietary server Application Programmer's Interface (API).
<BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR ALIGN=CENTER>
<BR>
<NOTE><A NAME="I2"></A>FastCGI is available from <A HREF="javascript:if(confirm('http://www.fastcgi.com/ \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://www.fastcgi.com/'" tppabs="http://www.fastcgi.com/"> http://www.fastcgi.com</A>. (See Figure C.1.) The site is the official resource to all FastCGI information. It has complete documentation and whitepapers on FastCGI. Also nice is a mailing list—a threaded archive that is available through the Web.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P><B> <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/Apachu/xc01.gif \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location. You should report this problem to the site\'s webmaster. \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/Apachu/xc01.gif'" tppabs="http://docs.rinet.ru:8080/Apachu/xc01.gif">Figure C.1. The FastCGI home page.</A></B>
<BR>
<P>FastCGI is a proposed open standard; this means that it is not currently widely accepted, but it has received a warm welcome by many significant people on the Internet who are responsible for setting the standards. More than likely, this welcome will turn into acceptance on both free and commercial Web server offerings, which will help it in becoming "blessed" from a standard point of view.
<BR>
<P>FastCGI is appealing not only because of its performance enhancements but because the effort required to migrate existing code is very small. As a bonus, software developed under this proposed standard has a high degree of portability. These portability issues help a great deal toward setting it as a viable candidate to become a standard, especially on installations that have committed extensive resources to CGI development.
<BR>
<P>FastCGI is not a development environment in terms of having to learn yet another programming language. In a very simplistic description, FastCGI it is a CGI program that uses additional libraries, so it does require that you learn an API. The basic API is tiny, though; one call is all you need to migrate many of your current programs.
<BR>
<BR>
<A NAME="E68E183"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>FastCGI Features</B></FONT></CENTER></H3>
<BR>
<P>The main features of FastCGI are as follows:
<BR>
<UL>
<LI>A huge increase in performance. FastCGI programs continue to live between requests, making their responsiveness faster and reducing delays due to forking and program initialization.
<BR>
<BR>
<LI>Programming language-independent implementation. Like CGI, you can develop your FastCGI application with a variety of languages. Currently there are programming libraries for Perl, C/C++, Tcl, and Java. Porting existing code to FastCGI is easy, allowing you to easily migrate your existing code base without having to redo what you have done.
<BR>
<BR>
<LI>FastCGI processes are isolated from the Web server core. Much like CGI, FastCGI applications offer greater security and reliability than developing a similar functionality as a module using a server API.
<BR>
<BR>
<LI>Server technology separation. There are FastCGI modules for various servers, including Apache, NCSA, and the Open Market Secure WebServer. For any other server that supports CGIs, the cgi-fcgi program, included in the FastCGI distribution, implements the FastCGI environment.
<BR>
<BR>
<LI>Distributed computing support. FastCGI applications can execute on a different host from the Web server. This allows you to offload FastCGI execution to other application servers, permitting your Web server to handle an increased load. FastCGI programs can run on any host that can be reached over TCP/IP.
<BR>
<BR>
<LI>The concept of <I>roles</I>. Traditional CGI programs fall into the responder role; they respond to some action initiated by a browser and send back some HTML. FastCGI programs can also perform other roles, such as a filter or as part of some authentication scheme. This allows for providing extra functionality that would usually be relegated to a server module. The currently available FastCGI module for Apache does not include support for roles other than responder, but this may change in the future.
<BR>
<BR>
</UL>
<BR>
<A NAME="E68E184"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Performance Enhancement</B></FONT></CENTER></H3>
<BR>
<P>The increase in performance alone would be a good enough reason to migrate CGIs to FastCGI, especially on loaded servers. This increase in performance is achieved primarily because FastCGI processes are persistent. Forking under UNIX is very expensive, and FastCGI addresses this issue by reusing processes. This saves on the initialization time and can also provide enhancements when data calculated by one call to the program can be reused in another transaction.
<BR>
<P>Unlike CGIs, which are forked every time there's a request for the functionality, FastCGI processes are reused. After a request is fulfilled, the process remains, waiting for additional requests.
<BR>
<P>Programs that rely on an interpreter such as Perl or Tcl can gain a great deal from this technology because the command interpreter will compile the program once, not once per call. The time required to do all this pre-run initialization is eliminated. On the program side, this can yield to enhancements such as establishing a connection with a database or some other process because the connection only needs to happen once. Add to this the load to launch the interpreter program, and the savings are significant.
<BR>
<P>What sort of performance gains can you obtain? According to information posted on the FastCGI Web site, Open Market's tests show the following:
<BR>
<TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >
<TR>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
Request
</FONT>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
Client, Server, and Application Processing Time
</FONT>
<TR>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
Static File
</FONT>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
21ms + 0.19ms/KB
</FONT>
<TR>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
FastCGI
</FONT>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
22ms + 0.28ms/KB
</FONT>
<TR>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
CGI
</FONT>
<TD VALIGN=top BGCOLOR=#80FFFF ><FONT COLOR=#000080>
59ms + 0.37ms/KB</FONT>
</TABLE><P>Add to this the cumulative time that it takes for an application to establish a TCP/IP connection to, say, a database. Under CGI, a process will have to initialize each time it is run. FastCGI can yield a performance increase of four times the speed of the same program used as CGI. In load terms, this could mean that your server could potentially handle four times your current CGI load. However, the level of enhancement will depend on the source of the bottleneck. If your database server is the current source of the problem, FastCGI cannot do much about that except reduce the number of connections that the database server will need to perform, perhaps giving it more time to process data instead.
<BR>
<BR>
<A NAME="E68E185"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>FastCGI API</B></FONT></CENTER></H3>
<BR>
<P>The FastCGI API has a handful of calls:
<BR>
<UL>
<LI>FCGI_Accept is used to implement the server connectivity and control the running of the FastCGI program.
<BR>
<BR>
<LI>FCGI_Finish gives you control after the FastCGI program has executed, but before running the next request.
<BR>
<BR>
<LI>FCGI_SetExitStatus is used to set the exit status of the request. Most CGI programs don't return meaningful exit status, so this call is seldom used.
<BR>
<BR>
<LI>FCGI_StartFileterData enables you to implement a special type of FastCGI application, called a <I>filter</I>. Currently the Apache implementation of the FastCGI module doesn't support roles, of which the filter type is a member, but this likely will change in the near future. Filters allow you to implement programs that will convert one data format to another on-the-fly (for example, TIFF to GIF).
<BR>
<BR>
</UL>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -