当前位置:编程问答 > CGI >

实战 FastCGI(转)一

答案:实战 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 ,利用 ISAPI 撰写网站应用程序,必须把应用程序编译成动态函式库,也就是 DLL 檔。它的执行速度也很快,但要遵循 ISAPI 的撰写规则和数据结构,程序发生错误时也会影响 IIS Server 的正常运作。
综观以上两种以 Web Server API 为主的方案 (其实 Apache 也有相对应的 Server API,只是用的人可能更少) ,它们的执行速度都很快,就产生动态网页而言比 CGI 快上好几倍。但是就程序开发者的角度2来看,它们有一些缺点:

1. NSAPI 及 ISAPI 与网站平台相依性太高 (Platform dependency),也就是说使用了 NSAPI 或 ISAPI 后,应用程序就完全受限于所使用的网站服务器平台,不能变换所使用的网站服务器。不像 CGI 完全不受网站平台的限制,可以在任何网站服务器 (Netscape, Microsoft IIS, Apache, NCSA)上执行。另外像 ISAPI 更只能限制在 Windows NT 平台上使用。
2. NSAPI 及 ISAPI 只提供 C 程序语言的界面,亦即开发者一定要使用 C 语言开发。不像 CGI 是与开发者所使用的程序语言完全无关,除了 C 之外,常用的还有 Perl,Tcl等。
3. Netscape Enterprise Server 和 Microsoft IIS 都是以多执行绪 (Multi-Threads) 的方式处理 NSAPI 及 ISAPI 的程序,所有执行绪共享同一块变量空间,因此在变量数据的处理上要特别小心,以确保每一个执行绪内的变量资料的安全,不会互相影响。
4. NSAPI 和 ISAPI 应用程序都是直接在服务器的执行行程 (process) 内被呼叫,如果程序当掉了,整个网站服务器都会被影响。CGI 当掉服务器会响应 Internal Server Error 的讯息,服务器本身不受影响。
5. NSAPI 和 ISAPI 应用程序必须被服务器呼叫才会被执行,侦错 (debug) 相当不容易。

1.3 更好的方法 - FastCGI
如果你正饱受 CGI 效率不佳之苦,又不想受限于 NSAPI 及 ISAPI ,也没有大笔银子去买昂贵的 Application Server,我建议你试试看 FastCGI。

不同于 NSAPI 及 ISAPI 以及其它的网页服务器语言 (如 ASP, PHP3, mod_perl),FastCGI 比较类似 CGI,它只是一个网站应用程序设计的规格,因此先天上不受任何网站服务器平台,操作系统平台,以及开发语言的限制,但又能大幅改善 CGI 效率不良的问题。FastCGI 的特色如下:

1. FastCGI 像是一个常驻 (long-live) 型的 CGI,它可以一直执行着,只要激活后,不会每次都要花费时间去 fork 一次 (这是 CGI 最为人诟病的 fork-and-execute 模式)。
2. FastCGI 可在任何平台上使用,Netscape Enterprise 及 IIS 都有 FastCGI 的模块可供使用,阿帕契 (Apache,以及利用 Apache 衍生出做的服务器) 上也有 mod_fastcgi 可用。
3. FastCGI 支持 C/C++,Perl,Tcl,Java,Python 等程序语言。
4. FastCGI 的应用程序亦兼容于 CGI。即 FastCGI 的应用程序也可以当成 CGI 来执行。
5. 现有的 CGI 程序要改写成 FastCGI 非常简单,最少可能只需要多加入三行程序代码。
6. FastCGI 的侦错方式与 CGI 大同小异,只要带入程序所需的环境变量及参数,即可在命令列模式执行或侦错。
7. FastCGI 应用程序的写作方式与 CGI 类似,除了几项原则要特别注意外,FastCGI 的写作方式跟 CGI 几乎一样,与学习 Web Server API 比较起来, FastCGI 简单多了。
8. FastCGI 支授分布式运算 (distributed computing),即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。

看到 FastCGI 这些特色后,是否跃跃欲试呢。下一章将介绍如何在 Apache 服务器上安装 FastCGI 的步骤。

上一个:在Windows NT 4.0下安装ActivePerl(这是何志强老兄写的呀!)被我收藏了!
下一个:实战 FastCGI(转)二

CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络,