实战 FastCGI

由此可见， FastCGI 激活之后，省去原本 CGI 程序中 fork，内存配置，建立数据库联机等步骤，处理每个联机请求的时间几乎等于 FCGI_Accept() 这个循环中运算所需的时间。如果妥善将每次联机请求时一样的程序代码从 FCGI_Accept() 循环抽出来，只保留每次会产生不同结果的部份，则程序处理每次联机请求的时间可以更短，整个网站的效率也可以大幅的提升。

了解 FastCGI 程序的基本架构后，可以发现一般的 CGI 程序，只要加入 FCGI_Accept() 这个 while 循环后，大概就可以变成 FastCGI 的程序了。

3.4 炼结 libfcgi.a 函式库
FastCGI 程序要炼结到 libfcgi.a 函式库才可正确产生出执行档，假设 libfcgi.a 的位置在 /usr/local/lib 这个目录下，我们在编译 (炼结时) 要加入 -L/usr/local/lib -lfcgi 的参数。


$ cc -o program.fcg program.o -L/usr/local/lib -lfcgi

3.5 撰写 FastCGI 程序的注意事项
由于 FastCGI 程序被激活后就常驻在内存之中，对每个 FastCGI 的执行行程 (running process) 而言，每次联机请求共享的变量空间是相同的，因些选写 FastCGI 程序要特别留意一些注意事项。

1. 记住，对每个 FastCGI 程序而言，只有 FCGI_Accept() 循环内的程序才是真正处理每次联机请求的主体，假设在程序中要读取和 CGI 有关的环境变量，或是使用者透过窗体 (form) 所输入的资料，必须在 FCGI_Accept() 循环内才处理。
2. 对每次联机请求会改变的变量，别忘了在处理新的联机请求前把变量初始化 (除非是有特殊用途) ，以避免变量值在不同的联机请求之间互相影响。
3. 在 FCGI_Accept() 循环中配置 (allocate) 的内存别忘了释放 (free)。在一般的 CGI 程序中， Memory Leak 不算是太大的问题，因为每处理完一次联机请求，所有用到的内存随着 CGI 程序的结束也被释放。但是 FastCGI 程序会一直常驻在内存中，如果在 FCGI_Accept() 中有配置额外的内存，在循环结束前没有释放掉，则每处理一次联机请求就吃掉一些系统的内存，多跑几次下来，系统资源大概就被耗光了。Memory leak 的问题是 FastCGI 最常见的错误，要特别小心处理。
4. FastCGI 程序和其所要引用的子程序中，用到 stdio.h 函式的部份，记得要改成 fcgi_stdio.h 。否则当程序在遇到 IO 的动作时就会发生 Core Dump 的情况。
5. 在 FCGI_Accept() 循环中使用 FCGI_Finish() 函式以取代 exit() 函式。原本 CGI 程序中发生错误时，可能直接呼叫 exit() 函式结束 CGI 行程，FastCGI 程序也可以如此，因为 mod_fastcgi 模块在 FastCGI 程序发生错误而意外结束时，会自动再激活另一个 FastCGI 的行程。但比较好的作法是呼叫 fcgi_stdio.h 中的 FCGI_Finish() 函式，呼叫 FCGI_Finish() 函式会跳出目前程序正在运算中的循环，回到 FCGI_Accept() 等待下一个联机请求。如此可以省去一些网站服务器激活新的 FastCGI 行程的负担。