摘要:接下來解析器會解析文件,初始化執(zhí)行環(huán)境,然后處理請求,再以規(guī)定規(guī)定的格式返回處理后的結(jié)果,退出進程。好了,是個協(xié)議,跟進程什么的沒關(guān)系。那又是什么呢是用來提高程序性能的。
前言
現(xiàn)在的CGI基本沒人使用,不安全以及性能極其低下,越來越多的使用web內(nèi)置擴展、fastCGI。例如微軟iis的ISAPI,apache的php模塊,nginx的php-cgi。CGI、內(nèi)置模塊、fastcgi這三種性能最好的要屬于fast_cgi速度最快,但是需要額外的進程。解析來看看CGI和FASTCGI有什么不同.
CGI方式介紹:
cgi在2000年或更早的時候用得比較多,以前web服務(wù)器一般只處理靜態(tài)的請求,如果碰到一個動態(tài)請求怎么辦呢?web服務(wù)器會根據(jù)這次請求的內(nèi)容,然后會fork一個新進程來運行外部c程序(或perl腳本...), 這個進程會把處理完的數(shù)據(jù)返回給web服務(wù)器,最后web服務(wù)器把內(nèi)容發(fā)送給用戶,剛才fork的進程也隨之退出。 如果下次用戶還請求改動態(tài)腳本,那么web服務(wù)器又再次fork一個新進程,周而復(fù)始的進行。
web內(nèi)置模塊介紹:
后來出現(xiàn)了一種更高級的方式是, web服務(wù)器可以內(nèi)置perl解釋器或php解釋器。 也就是說這些解釋器做成模塊的方式,web服務(wù)器會在啟動的時候就啟動這些解釋器。 當(dāng)有新的動態(tài)請求進來時,web服務(wù)器就是自己解析這些perl或php腳本,省得重新fork一個進程,效率提高了。
fastcgi方式介紹:
fastcgi的方式是,web服務(wù)器收到一個請求時,他不會重新fork一個進程(因為這個進程在web服務(wù)器啟動時就開啟了,而且不會退出),web服務(wù)器直接把內(nèi)容傳遞給這個進程(進程間通信,但fastcgi使用了別的方式,tcp方式通信),這個進程收到請求后進行處理,把結(jié)果返回給web服務(wù)器,最后自己接著等待下一個請求的到來,而不是退出.
fastcgi跟cgi的區(qū)別表格:
舉個例子: 服務(wù)端現(xiàn)在有個10萬個字單詞, 客戶每次會發(fā)來一個字符串,問以這個字符串為前綴的單詞有多少個。 那么可以寫一個程序,這個程序會建一棵trie樹,然后每次用戶請求過來時可以直接到這個trie去查找。 但是如果以cgi的方式的話,這次請求結(jié)束后這課trie也就沒了,等下次再啟動該進程時,又要新建一棵trie樹,這樣的效率就太低下了。 而用fastcgi的方式的話,這課trie樹在進程啟動時建立,以后就可以直接在trie樹上查詢指定的前綴了。
引用評論(https://segmentfault.com/q/10...)
首先,CGI是干嘛的?CGI是為了保證web server傳遞過來的數(shù)據(jù)是標準格式的,方便CGI程序的編寫者。
web server(比如說nginx)只是內(nèi)容的分發(fā)者。比如,如果請求/index.html,那么web
server會去文件系統(tǒng)中找到這個文件,發(fā)送給瀏覽器,這里分發(fā)的是靜態(tài)數(shù)據(jù)。好了,如果現(xiàn)在請求的是/index.php,根據(jù)配置文件,nginx知道這個不是靜態(tài)文件,需要去找PHP解析器來處理,那么他會把這個請求簡單處理后交給PHP解析器。Nginx會傳哪些數(shù)據(jù)給PHP解析器呢?url要有吧,查詢字符串也得有吧,POST數(shù)據(jù)也要有,HTTP
header不能少吧,好的,CGI就是規(guī)定要傳哪些數(shù)據(jù)、以什么樣的格式傳遞給后方處理這個請求的協(xié)議。仔細想想,你在PHP代碼中使用的用戶從哪里來的。當(dāng)web
server收到/index.php這個請求后,會啟動對應(yīng)的CGI程序,這里就是PHP的解析器。接下來PHP解析器會解析php.ini文件,初始化執(zhí)行環(huán)境,然后處理請求,再以規(guī)定CGI規(guī)定的格式返回處理后的結(jié)果,退出進程。web
server再把結(jié)果返回給瀏覽器。
好了,CGI是個協(xié)議,跟進程什么的沒關(guān)系。那fastcgi又是什么呢?Fastcgi是用來提高CGI程序性能的。
提高性能,那么CGI程序的性能問題在哪呢?"PHP解析器會解析php.ini文件,初始化執(zhí)行環(huán)境",就是這里了。標準的CGI對每個請求都會執(zhí)行這些步驟(不閑累啊!啟動進程很累的說!),所以處理每個時間的時間會比較長。這明顯不合理嘛!那么Fastcgi是怎么做的呢?首先,F(xiàn)astcgi會先啟一個master,解析配置文件,初始化執(zhí)行環(huán)境,然后再啟動多個worker。當(dāng)請求過來時,master會傳遞給一個worker,然后立即可以接受下一個請求。這樣就避免了重復(fù)的勞動,效率自然是高。而且當(dāng)worker不夠用時,master可以根據(jù)配置預(yù)先啟動幾個worker等著;當(dāng)然空閑worker太多時,也會停掉一些,這樣就提高了性能,也節(jié)約了資源。這就是fastcgi的對進程的管理。
那PHP-FPM又是什么呢?是一個實現(xiàn)了Fastcgi的程序,被PHP官方收了。
大家都知道,PHP的解釋器是php-cgi。php-cgi只是個CGI程序,他自己本身只能解析請求,返回結(jié)果,不會進程管理(皇上,臣妾真的做不到啊!)所以就出現(xiàn)了一些能夠調(diào)度php-cgi進程的程序,比如說由lighthttpd分離出來的spawn-fcgi。好了PHP-FPM也是這么個東東,在長時間的發(fā)展后,逐漸得到了大家的認可(要知道,前幾年大家可是抱怨PHP-FPM穩(wěn)定性太差的),也越來越流行。
好了,最后來回來你的問題。
網(wǎng)上有的說,fastcgi是一個協(xié)議,php-fpm實現(xiàn)了這個協(xié)議
對。
有的說,php-fpm是fastcgi進程的管理器,用來管理fastcgi進程的
對。php-fpm的管理對象是php-cgi。但不能說php-fpm是fastcgi進程的管理器,因為前面說了fastcgi是個協(xié)議,似乎沒有這么個進程存在,就算存在php-fpm也管理不了他(至少目前是)。
有的說,php-fpm是php內(nèi)核的一個補丁以前是對的。因為最開始的時候php-fpm沒有包含在PHP內(nèi)核里面,要使用這個功能,需要找到與源碼版本相同的php-fpm對內(nèi)核打補丁,然后再編譯。后來PHP內(nèi)核集成了PHP-FPM之后就方便多了,使用--enalbe-fpm這個編譯參數(shù)即可。
有的說,修改了php.ini配置文件后,沒辦法平滑重啟,所以就誕生了php-fpm
是的,修改php.ini之后,php-cgi進程的確是沒辦法平滑重啟的。php-fpm對此的處理機制是新的worker用新的配置,已經(jīng)存在的worker處理完手上的活就可以歇著了,通過這種機制來平滑過度。
還有的說PHP-CGI是PHP自帶的FastCGI管理器,那這樣的話干嗎又弄個php-fpm出
不對。php-cgi只是解釋PHP腳本的程序而已。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/31044.html
摘要:接下來解析器會解析文件,初始化執(zhí)行環(huán)境,然后處理請求,再以規(guī)定規(guī)定的格式返回處理后的結(jié)果,退出進程。好了,是個協(xié)議,跟進程什么的沒關(guān)系。那又是什么呢是用來提高程序性能的。 前言 現(xiàn)在的CGI基本沒人使用,不安全以及性能極其低下,越來越多的使用web內(nèi)置擴展、fastCGI。例如微軟iis的ISAPI,apache的php模塊,nginx的php-cgi。CGI、內(nèi)置模塊、fastcgi...
摘要:深入?yún)f(xié)議從功能上來講,協(xié)議已經(jīng)完全能夠解決服務(wù)器與應(yīng)用之間的數(shù)據(jù)通信問題。消息頭信息主要的消息頭信息如下用于表示協(xié)議版本號。從服務(wù)器發(fā)送到應(yīng)用,表示中止一個處理中的請求。另外我們還需要明確一點就是服務(wù)器與進程間通信是無序的。 本文首發(fā)于 深入剖析 Web 服務(wù)器與 PHP 應(yīng)用之間的通信機制 - 掌握 CGI 和 FastCGI 協(xié)議的運行原理,轉(zhuǎn)載請注明出處! 身為一名使用 PHP ...
摘要:程序處理完后,原本發(fā)送到標準輸出的信息會被轉(zhuǎn)到服務(wù)器,服務(wù)器再將結(jié)果返回給客戶端。通過相同的連接方式,響應(yīng)返回給服務(wù)器。 CGI 什么是CGICGI(Common Gateway Interface)是一個標準協(xié)議,它為web服務(wù)器提供了一個標準的協(xié)議,以便于服務(wù)器可以像運行命令行接口程序那樣來運行第三方程序,這些第三方程序可以動態(tài)地生成web頁面。這些第三方程序被稱為CGI腳本(滿足...
摘要:程序處理完后,原本發(fā)送到標準輸出的信息會被轉(zhuǎn)到服務(wù)器,服務(wù)器再將結(jié)果返回給客戶端。通過相同的連接方式,響應(yīng)返回給服務(wù)器。 CGI 什么是CGICGI(Common Gateway Interface)是一個標準協(xié)議,它為web服務(wù)器提供了一個標準的協(xié)議,以便于服務(wù)器可以像運行命令行接口程序那樣來運行第三方程序,這些第三方程序可以動態(tài)地生成web頁面。這些第三方程序被稱為CGI腳本(滿足...
摘要:程序處理完后,原本發(fā)送到標準輸出的信息會被轉(zhuǎn)到服務(wù)器,服務(wù)器再將結(jié)果返回給客戶端。通過相同的連接方式,響應(yīng)返回給服務(wù)器。 CGI 什么是CGICGI(Common Gateway Interface)是一個標準協(xié)議,它為web服務(wù)器提供了一個標準的協(xié)議,以便于服務(wù)器可以像運行命令行接口程序那樣來運行第三方程序,這些第三方程序可以動態(tài)地生成web頁面。這些第三方程序被稱為CGI腳本(滿足...
閱讀 1778·2023-04-25 14:33
閱讀 3378·2021-11-22 15:22
閱讀 2177·2021-09-30 09:48
閱讀 2684·2021-09-14 18:01
閱讀 1740·2019-08-30 15:55
閱讀 3006·2019-08-30 15:53
閱讀 2139·2019-08-30 15:44
閱讀 648·2019-08-30 10:58