实战 FastCGI
作 者： 许明彦
Abstract:
当网站日益走红，联机人数直线上升而心中暗自窃喜之时，突然客服中心涌来大批反应电话：『网站连不上去』、『按下去等好久画面才出来』、『一直出现 Server Too Busy...』．．．。看来又要把硬件升级了，但是再加更多的内存，更多 CPU、换更贵的机器真的能解决问题吗？有没有比较省钱的方法呢？本文将介绍如何在阿帕契服务器上安装 FastCGI 的模块，如何设定及使用 FastCGI 网站应用程序，让你的网站程序在现有的架构上以全速执行。
----------------------------------------------------------------------------
1. 克服 CGI 的瓶颈
1.1 令人头痛的效率问题
1.2 一些解决之道
1.3 更好的方法 - FastCGI
2. 安装 FastCGI
2.1 在阿帕契服务器上安装 FastCGI 模块
2.1.1 标准安装 (利用 APACI)
2.1.2 将 mod_fastcgi 安装成一个 DSO
2.2 加入使用 mod_fastcgi 的相关设定
2.3 安装 FastCGI 开发套件
2.4 测试 FastCGI
2.5 安装 FCGI 模块 for Perl
3. 撰写 FastCGI 应用程序
3.1 程序架构
3.2 引入 fcgi_stdio.h 标头档
3.3 FastCGI 处理循环
3.4 炼结 libfcgi.a 函式库
3.5 撰写 FastCGI 程序的注意事项
4. FastCGI 有多快？
4.1 评比工具 - ApacheBench
4.2 CGI vs. FastCGI
4.3 找出 Memory Leak
5. 参考
About this document ...
----------------------------------------------------------------------------
1. 克服 CGI 的瓶颈
1.1 令人头痛的效率问题
拜 CGI 之赐，网站不再只有固定不变的图形和文字，藉由程序动态产生的网页可以让网站好象『活』了起来。小从简单的网页计数器，留言版，大至处理众多资料的搜寻引擎，可做线上实时交易的电子商务、网络下单等。CGI 简单、开放、跨平台、与程序语言独立的特性，使得撰写网站应用程序变得很容易。
但随着网站使用量日增，这些 CGI 程序从原本动态网页的功臣，突然成了网站效率的头号杀手。由于 CGI 先天的限制1，突然涌入大量的联机请求 (request) ，常会造成网站主机瞬间资源被占用，彷佛『当机』一样，或是处理速度变得很慢。
另一个常遇到的限制是和数据库联机的问题，如果 CGI 程序后端需要联机至数据库执行指令再取得结果，突然大量的联机请求可能会超过数据库系统容许联机的上限 (例如数据库系统使用者数目的限制)。
因此对一个主要以使用 CGI 程序制作动态网站的开发者而言，解决 CGI 执行效率瓶颈成了一个头痛的问题。以一个股市实时行情报价的网站为例，每天的联机请求将近八成集中在股市开盘的尖峰时段内，更是对网站应用程序极大的考验。
1.2 一些解决之道
现在已经有许多方案被提出来以解决 CGI 执行效率上的瓶颈，在『用 FastCGI 加速你的网站』一文中也有简单的说明，这里仅就笔者在开发股市实时报价的网站应用程序时，所尝试过的一些方法提出个人的经验和意见。以笔者的案例而言，原本的 CGI 程序是以 C 语言写的，并且用了其它的 C 函式库所以下列的方法主要是以提供 C 语言开发环境的方案为主。
NSAPI
由于原先网站是在 Unix 系统上，网站服务器使用网景 Enterprise Server，所以最早想到是用 NSAPI 来改写网站应用程序。在网景的网站上有非常详细的 NSAPI 使用手册，不幸的是没有中文手册。要用 NSAPI 改写网站应用程序最麻烦的是你要把所有程序编译成动态函式库 (share library)，以供 Enterprise Server 在 run-time 时期可以动态呼叫这些程序。由于利用 NSAPI 所写的程序是直接从 Web Server 的执行空间内被呼叫，所以速度最快，但是程序必须遵循 Enterprise Server 的撰写规则，而且一旦程序发生错误， Web Server 也会受影响。
ISAPI
相较于 NSAPI ，在 Microsoft NT IIS (Internet Information Server) 平台就是 ISAPI 了。类似 NSAPI ，利
上一页 下一页
