=============
Apache+SCGI Apache 前端處理用戶請求，負(fù)責(zé)靜態(tài)頁面
mod_scgi 充當(dāng) scgi client， 將http請求中動態(tài)部分發(fā)給 scgi runner。
=============參考：
http://www.pc51.net/server/web/apache/2006-12-21/334.html關(guān)注SCGI,一種更佳的高性能CGI方案
目前，rubyonrails可以采用服務(wù)器方案有：
1。 Webrick
2。 Apache(lighttpd) + CGI
3。 Apache+FastCGI
4。 Lighttpd + FastCGI
5。 Apache(lighttpd)+SCGI
其中，Webrick是一個玩具，不支持并發(fā)請求，只能作為開發(fā)工具進(jìn)行調(diào)試。而CGI方式就直接踢出，在性能上是難以忍受的。 FastCGI雖然性能卓越（據(jù)稱是傳統(tǒng)CGI程序的5倍），但是在Apache中非常不穩(wěn)定，經(jīng)常會出現(xiàn)500錯誤。相對來說Lighttpd+FastCGI的方案比較穩(wěn)定，性能也不錯，但lighttpd畢竟不是一個十分流行的http服務(wù)器，大部分人都不熟悉此服務(wù)，擴(kuò)展模塊也相對較少，另外似乎還有些bug，沒有apache那么健壯。
在這幾個方案中能夠兼具高性能和高穩(wěn)定性的莫過于Apache+SCGI方案。SCGI是用來替換傳統(tǒng)CGI的新的CGI協(xié)議，以Client/Server的方式實(shí)現(xiàn)，具有和FastCGI一樣優(yōu)秀的性能，同時又在穩(wěn)定性方面遠(yuǎn)遠(yuǎn)超過FastCGI, 該方案在Python Web領(lǐng)域應(yīng)用較多。
一般搭建一個SCGI環(huán)境需要準(zhǔn)備，Apache，mod_scgi, scgi runner等軟件，其中apache做為前端http服務(wù)器處理用戶請求并且負(fù)責(zé)靜態(tài)文件，而mod_scgi是apache的一個擴(kuò)展模塊，該模塊實(shí)現(xiàn)了SCGI協(xié)議的client部分，負(fù)責(zé)將http請求中的動態(tài)部分發(fā)給SCGI服務(wù)器，即SCGI Runner,在rubyonrails社區(qū)，已經(jīng)有人開發(fā)了SCGI Rails Runner--SRR，只需要將一個腳本放你的rails程序的script目錄中，運(yùn)行該腳本就會建立一個SCGI Server,等待并且處理SCGI Client(mod_scgi)轉(zhuǎn)發(fā)的請求。
對SCGI有興趣的朋友，可以查看這些內(nèi)容：
http://www.mems-exchange.org/software/scgi/
http://www.zedshaw.com/projects/scgi_rails/
另外，由于RubyOnRails特殊的url rewrite機(jī)制，官方目前提供的apache配置模板可能會使一些看起來是靜態(tài)文件的url無法被rubyonrails處理，如typo里的rss: /xml/rss.xml，不過，rails社區(qū)的Kyle等人已經(jīng)搞出了兩個方案，而SRR的作者也打算采用他們的方案。當(dāng)然，一般情況下，使用官方的配置模板就已經(jīng)能夠處理大部分url。對這個問題有興趣的朋友可以在rails的郵件列表中搜索：scgi apache, 最近的幾篇郵件應(yīng)該有提到。