PHP相關概念及配置

基本概念簡介

　　首先想一個問題，客戶端訪問Web服務器，服務器將對應的資源響應給客戶端，將屬性還原成對應的格式後，瀏覽器可否解碼對應格式的文檔？

　　MIME機制的出現就可以讓http協議傳送非文本信息了，如傳一個MP3格式的音樂文件傳送給客戶端後，那麼客戶端可否使用瀏覽器去播放MP3格式的音樂呢？顯然是不行的，瀏覽器僅可以解碼HTML格式的文檔。那麼對於這樣的多媒體音樂它應該怎麼去處理呢？瀏覽器可經過瀏覽器插件或調用與之匹配的外部程序來對多媒體等格式的文件進行解碼，而瀏覽器自己不可以播放音樂，要麼是瀏覽器有插件能夠播放音樂，要麼是主機上有其它程序播放音樂，而瀏覽器能夠直接調用那個程序執行。那這樣一來瀏覽器處理文件的能力大大加強了，但其有一個隱患，若對方發送過來一段惡意代碼，而這個代碼偏偏是主機上某個程序能夠執行的，所以有安全問題。

　　所以，通常來講咱們容許服務器端發送過來的僅僅是靜態文檔，像MP3音樂，還原成MP3後仍是靜態的，它是一種靜態格式，不是一種程序，而是一個文件。那若是用戶發來的是一個用C語言編譯好的程序，那麼發送到客戶端後客戶端沒法識別，沒法識別就不能直接去執行它，咱們必需要調用一個外部程序執行它，這樣就安全不少。

 

動態網站：

　　咱們在服務器端或客戶端執行了一段腳本或一段程序，這個程序的執行結果根據不一樣用戶、不一樣客戶端、不一樣主機甚至不一樣的應用場景而不一樣，這種才稱爲是動態網站。因此動態網站必定是根據用戶的請求做出對應響應的，甚至於對不一樣用戶返回的內容是不同的，根據客戶端的請求來返回不一樣結果的。　　

　　動態網站有客戶端動態和服務器端動態的概念：

　　客戶端動態意味着服務器端開發的源程序須要下載到本地而且在客戶端本地的運行環境中執行而且將執行結果經過瀏覽器顯示出來，這種就稱做客戶端動態。但若是容許在客戶端隨意執行腳本或程序的話，那麼若是這個網站的製做者寫了一段惡意代碼或程序的話，甚至於客戶被輕易的種上木馬，因此有安全隱患，所以咱們通常來說不指望也不建議使用客戶端動態；像早期Windows上的一種技術ActiveX，這就是一種在客戶端執行程序的機制，還有像早期Java語言開發的Applet，Applet是Java開發的小程序，這個小程序須要在JVM（JVM是虛擬一個Java的運行沙箱，一個盒子，其中可以運行Java程序，Java須要獨特的運行時環境，須要裝載Java所須要的類、庫等等，還須要管理Java的生命週期，因此這是一個獨特的專門用來管理Java程序的一種虛擬化的環境）上運行，Applet可以讓Web程序員開發出一個小程序，這個小程序直接放在Web服務器站點的目錄當中，然後客戶端能夠直接訪問這個小程序，把這個小程序下載至本地，並在本地的Java虛擬機中運行。因此得爲瀏覽器安裝JVM插件，但在客戶端運行程序是不安全的，好在Java的程序只能在JVM中運行，若是破壞的話，破壞的在很大程度上也是JVM自己。但Applet仍是要求在客戶端安裝一個插件進行配置，因此這對客戶端提出了較高的要求，這對衆多的用戶來講是不可忍受的。由此，逐漸的把程序的運行機制返回至服務器端。

　　服務器端動態：

　　CGI：讓服務器可以執行程序的技術，CGI是一種協議，它可以讓Web服務器進程根據那個對應的程序的不一樣調用對應的執行環境來運行那個對應的程序的文件，而且可以讓程序的文件的運行結果從新取回至Web進程，這種協議就是CGI。其實任何語言都是能夠開發動態網站的，而有些語言相比較來講，更適合開發Web應用程序（webapp，指的是在服務器運行的Web程序，這個程序在客戶端訪問這個頁面的時候不是直接返回給客戶端的，而是如今服務器端調用對應的執行程序執行後將結果格式化成HTML文檔返回給客戶端的）。

 

編程語言：

　　靜態語言（編譯型語言）：（靜態語言是強類型的，並且通常來說只有先編譯才能運行）

　　　　C、C++、Java

　　　　優勢：性能好（相比較而言，由於靜態語言須要編譯才能運行，像C或C++，編譯完成後，只要它所依賴的庫文件都存在就能直接運行，不依賴於任何外在的東西，它是一個具備獨立執行入口的程序，並且它自己就是二進制格式的，因此運行速度很是快。）

　　　　缺點：每一次改動都得從新編譯、開發週期長、維護成本大（編譯可能須要很長時間，最關鍵的是編譯好的程序，發現錯誤後還得從新編譯，所以靜態語言的錯誤查找、錯誤追蹤、調試都是比較困難的，因此在這方面不如動態語言便捷，每一次改動都得從新編譯。所以，像C/C++更適合開發底層項目，對性能要求很是高的場景（實時場景），如開發導彈控制程序、數據庫服務器軟件、操做系統、驅動程序等，比解釋性語言性能至少提升30%以上）。

　　　　由於C/C++作的很底層，可以直接操縱硬件，因此性能很是好，以致於它們的用戶接口不是那麼的好，提供的庫也不是那麼規範，因此衆多的功能都得本身手動去「造」，如造一輛汽車，輪胎的橡膠本身種、鋁材本身生產。而動態語言等最接近用戶的語言，它們有衆多的別人開發好的模塊，那就意味着輪子別人造好了，玻璃也造好了，拿過來一拼湊一輛車就造好了，開發週期很是短，所以靜態語言開發週期長，維護成本大。

　　動態語言（解釋性語言）：不須要編譯，弱類型，變量能夠在使用時直接拿來就用，不用事先聲明。更重要的是在運行的時候用一個解釋器解釋執行便可。

　　　　shell、Perl、Python

　　　　優勢：便於維護、有衆多模塊、開發週期短、開發成本低、維護成本小；

　　　　缺點：性能差；

　　Facebook使用動態語言開發網站，可是開發完成之後它們內部有一個專門的工具，這個工具可以將動態語言開發的程序轉換成靜態語言，這樣就結合了動態語言和靜態語言的好處。如：使用PHP開發程序，開發成本小、開發效率高，開發完成之後，他們本身公司有一個轉換器，可以將PHP開發的程序轉換成C++的程序，然後將C++編譯當作網站程序運行起來。用戶一訪問是一個C++程序，並且是編譯好的，直接就能夠運行了，這樣速度就很是快了。這個轉換器就是Hiphop。

　　PHP --> Hiphop --> C++

　　因此Facebook這樣的站點性能是很是好的。

　　不管如何，咱們應該使用動態語言開發動態語言，由於開發速度是比較快的、週期是比較短的，並且維護起來比較方便。儘管如此，也不是全部動態語言都適合開發Web頁面，如bash。

　　bash自己雖然是動態語言，但這個動態語言處理常見的Web應用場景的功能是很是小的，如：開發一個論壇，論壇中的衆多用戶要發帖、註冊、在線、討論，這些數據應該放在哪呢？bash如何有效跟這些數據交互呢？怎麼使用bash快速的完成一段動做，一些特殊的處理機制，好比統計一下今天有哪些用戶在線，每個用戶發了多少帖子，這些都是比較困難的，因此bash這種腳本語言拿來實現系統自動化則可，可是拿來開發Web程序是不合適的。

　　那麼哪些語言適合開發Web站點呢？

　　Perl早期也不適合,它早期是腳本語言，單比bash功能更強一些，可是後來有人爲Perl作了擴展，爲Perl提供了一種模塊，這種模塊提供了之後使得Perl可以快速構建Web服務器站點。包括Python也是，Python基於某些框架後後卻能快速開發Web服務器程序，Python開發Web服務器站點的框架叫作Django；Java一樣如此，也不適合開發Web，後來設計了一種特殊的JSP類使得Java的生命週期能夠在Web容器中進行了，因此使得使用了JSP這種語言也可以快速開發Web站點了，Java的JSP一般要運行在更快速的Web開發框架SSH。它們都須要依賴額外的框架，包括Ruby自己也是一種腳本語言，開發服務器站點須要的一種框架叫rails，因此有一種語言叫Ruby on rails，簡稱ror。

　　PHP不須要框架便可開發Web服務器站點，由於它自己設計就是用來開發Web服務器應用程序，固然還有ASP。

學習編程的步驟：

　　基本語法：控制結構、面向對象...

　　算法、數據結構

　　編譯原理（運行原理）

　　須要思考怎麼利用計算機自己的特性實現高性能開發，如高效的利用CPU的寄存器實現運算。

 

PHP相關知識

PHP（PHP is Hypertext Preprocessor，超文本預處理器）

　　可以將超文本事先在服務器上運行一下後，將結果返回給服務器。所以稱爲預處理器。

　　任何一種語言開發的程序，如bash開發的程序，咱們在運行的時候，若是一不當心將它裏面的一個關鍵字寫錯了，咱們指望結果解釋器會提示語法錯誤，而且不讓執行，那麼解釋器怎麼知道有語法錯誤呢？

　　因此通常來說，任何一種編程語言，它的解釋器或編譯器這種工具須要有幾個能力：

• 詞法分析：把每個語句經過空格做爲切片，看看哪一個是關鍵字、哪一個是變量、哪一個是用戶定義的、哪些是數據、哪些是控制結構等等，這叫詞法分析。分析關鍵字，找出其中的變量聲明等等相關功能；
• 語法分析：判斷整個程序當中有沒有語法上的錯誤；
• 生成執行路徑：轉換成可執行格式，編譯或解釋執行；

　　而parser就是一個分析器，它能作詞法分析、句法分析的。

　　　　

　　PHP自己是一種解釋性語言，意味着PHP開發的程序要想執行，只須要用PHP解釋器解釋（即：詞法分析、語法分析、執行）就能夠了，但這個速度是很是慢的。要想提升速度，只需將PHP源代碼（source code） --> 編譯（不是靜態編譯（不是用戶手動編譯），仍是PHP解釋器編譯的）成二進制 --> PHP解釋器執行二進制格式。因此zend Engine的出現將PHP執行由原本解釋執行（此時只有一個階段）轉換成了先編譯後執行的過程。

    這就意味着未來去訪問任何一個PHP頁面的時候，這個頁面首先在服務器上先編譯一下，因此結果是第一次訪問慢，第二次訪問直接執行編譯號的二進制格式了，因此速度要快的多。很顯然，把PHP程序放上去後，挨個的編譯好了以後，再讓用戶訪問速度就提高了。因此出現了Zend Engine後，將整個程序變成了兩段式的。首先詞法分析、句法分析、編譯，然後執行。而它的編譯結果叫作opcode（PHP的操做碼）。opcode接近於二進制格式，可是不能獨立執行，雖然是二進制格式，但跟Java程序同樣，只能在JVM中運行，因此能夠把Zend理解成opcode或PHP的虛擬機。所以，它只能在Zend Engine中運行。

    PHP每一次編譯時，編譯的結果存放的位置比較獨特，這個編譯的結果opcode不是放在磁盤上的，而是放在內存中的，因此咱們說這是一種動態編譯的中間語言，源程序都在磁盤上，那這就帶來一個問題，若是某一個特定用戶訪問的時候，他啓動了一個PHP進程，這個進程發現用戶訪問的是一個文件，假如叫1.php，而第二個用戶啓動了第二個PHP進程，同時第二個用戶訪問的仍是1.php，但這兩個用戶訪問的進程不是同一個進程，並且用戶所訪問的這個文件須要先編譯再執行，那這個編譯是由Zend Engine負責完成，那Zend Engine編譯好後放在內存中的對應進程的地址空間當中。而進程的地址空間對於每一個進程都是不一樣的，並且數據是不互通的，那意味着對於第一個用戶訪問的zend Engine訪問的編譯結果第二個進程不能用到這個加速機制。因此每個進程都須要獨立編譯，那使得PHP的執行效率是比較慢的，就算編譯了，在同一個進程內部很快，同一個文件被屢次，之後再訪問速度都會很快，可是其它進程訪問同一個文件不會被加速的。那麼可否有一個機制讓二者都能加速呢？

    能夠提供一個程序，這個程序能提供一個緩存，將任何一個程序所編譯的opcode放在這個緩存中間，並且這些程序均可以到緩存中去取這個編譯的結果。須要注意的是，此時任何一個程序編譯好的opcode再也不放在本身的地址空間中，而是放在緩存空間當中，注意這個緩存就是一個地址空間，而這個空間是能夠被衆多的PHP進程所共享的，那所以第一個PHP進程編譯好放在這，第二個進程就能夠直接使用了，因此只要不涉及到私有數據（信息），這些進程直接均可以共享編譯結果。而這個程序就叫作PHP的加速器（或者叫PHP的opcode緩存器）。

 

1、PHP簡介

　　PHP是通用服務器端腳本編程語言，其主要用於web開發以實現動態web頁面，它也是最先實現將腳本嵌入HTML源碼文檔中的服務器端腳本語言之一。同時，php還提供了一個命令行接口，所以，其也能夠在大多數系統上做爲一個獨立的shell來使用。

　　Rasmus Lerdorf於1994年開始開發PHP，它起初是一組被Rasmus Lerdorf稱做「Personal Home Page Tool」 的Perl腳本， 這些腳本能夠用於顯示做者的簡歷並記錄用戶對其網站的訪問。後來，Rasmus Lerdorf使用C語言將這些Perl腳本重寫爲CGI程序，還爲其增長了運行Web forms的能力以及與數據庫交互的特性，並將其重命名爲「Personal Home Page/Forms Interpreter」或「PHP/FI」。此時，PHP/FI已經能夠用於開發簡單的動態web程序了，這便是PHP 1.0。1995年6月，Rasmus Lerdorf把它的PHP發佈於comp.infosystems.www.authoring.cgi Usenet討論組，今後PHP開始走進人們的視野。1997年，其2.0版本發佈。

　　1997年，兩名以色列程序員Zeev Suraski和Andi Gutmans重寫的PHP的分析器(parser)成爲PHP發展到3.0的基礎，並且今後將PHP重命名爲PHP: Hypertext Preprocessor。此後，這兩名程序員開始重寫整個PHP核心，並於1999年發佈了Zend Engine 1.0，這也意味着PHP 4.0的誕生。2004年7月，Zend Engine 2.0發佈，由此也將PHP帶入了PHP5時代。PHP5包含了許多重要的新特性，如加強的面向對象編程的支持、支持PDO(PHP Data Objects)擴展機制以及一系列對PHP性能的改進。

2、PHP Zend Engine

　　Zend Engine是開源的、PHP腳本語言的解釋器，它最先是由以色列理工學院(Technion)的學生Andi Gutmans和Zeev Suraski所開發，Zend也正是此二人名字的合稱。後來兩人聯合創立了Zend Technologies公司。

　　Zend Engine 1.0於1999年隨PHP 4發佈，由C語言開發且通過高度優化，並可以作爲PHP的後端模塊使用。Zend Engine爲PHP提供了內存和資源管理的功能以及其它的一些標準服務，其高性能、可靠性和可擴展性在促進PHP成爲一種流行的語言方面發揮了重要做用。

　　Zend Engine的出現將PHP代碼的處理過程分紅了兩個階段：首先是分析PHP代碼並將其轉換爲稱做Zend opcode的二進制格式(相似Java的字節碼)，並將其存儲於內存中；第二階段是使用Zend Engine去執行這些轉換後的Opcode。

3、PHP的Opcode

　　Opcode是一種PHP腳本編譯後的中間語言，就像Java的ByteCode,或者.NET的MSL。PHP執行PHP腳本代碼通常會通過以下4個步驟(確切的來講，應該是PHP的語言引擎Zend)：

一、Scanning(Lexing) —— 將PHP代碼轉換爲語言片斷(Tokens)（即詞法分析（詞法掃描））

二、Parsing —— 將Tokens轉換成簡單而有意義的表達式（語法分析，Parsing與parse是兩碼事，如把數值賦值成變量的過程，通常來說是在這完成）

三、Compilation —— 將表達式編譯成Opocdes

四、Execution —— 順次執行Opcodes，每次一條，從而實現PHP腳本的功能

4、php的加速器

　　基於PHP的特殊擴展機制如opcode緩存擴展也能夠將opcode緩存於php的共享內存中，從而可讓同一段代碼的後續重複執行時跳過編譯階段以提升性能。由此也能夠看出，這些加速器並不是真正提升了opcode的運行速度，而僅是經過分析opcode後並將它們從新排列以達到快速執行的目的。

常見的php加速器有：

一、APC (Alternative PHP Cache)

遵循PHP License的開源框架，PHP opcode緩存加速器，目前的版本不適用於PHP 5.4。項目地址，http://pecl.php.net/package/APC。

二、eAccelerator

源於Turck MMCache，早期的版本包含了一個PHP encoder和PHP loader，目前encoder已經不在支持。項目地址， http://eaccelerator.net/。

三、XCache

快速並且穩定的PHP opcode緩存，通過嚴格測試且被大量用於生產環境。項目地址，http://xcache.lighttpd.net/

四、Zend Optimizer和Zend Guard Loader

Zend Optimizer並不是一個opcode加速器，它是由Zend Technologies爲PHP5.2及之前的版本提供的一個免費、閉源的PHP擴展，其可以運行由Zend Guard生成的加密的PHP代碼或模糊代碼。 而Zend Guard Loader則是專爲PHP5.3提供的相似於Zend Optimizer功能的擴展。項目地址，http://www.zend.com/en/products/guard/runtime-decoders

    （php是一個網站程序，而這個源代碼要拿來執行的，若是咱們做爲一個商業公司開發一個源代碼程序，想提供給衆多公司都能使用，那賣給第一個公司後，第一個公司拿來作盜版的話會很簡單，那爲了不盜版，須要把PHP源代碼加密，一加密看到的就是亂碼，那就沒辦法賣了，但能夠給使用碼，將這個使用碼放在公司的服務器上能運行，這就是所謂的受權碼，如今問題是，要把PHP加密後作成一堆亂碼了，PHP解釋器就不能解釋執行了，而Zend Optimizer可以識別加密後的代碼，用Zend Guard加密，用Zend Optimizer去執行。因此就能實現PHP加密了。）

五、NuSphere PhpExpress

NuSphere的一款開源PHP加速器，它支持裝載經過NuSphere PHP Encoder編碼的PHP程序文件，並可以實現對常規PHP文件的執行加速。項目地址，http://www.nusphere.com/products/phpexpress.htm

（做爲運維未來對到公司工做的時候，維護的頗有可能維護的就是一個PHP服務器或JSP服務器，因此上述內容必定要弄清楚，理解這段原理未來才能知道怎麼去優化服務器的執行的，爲何要裝xcache？它到底在多大程度上起到了加速做用，怎麼去調整xcache的性能，創建了一個緩存，它確定有一個緩存空間，緩存空間有多大，緩存中的條目應該緩存多長時間，有效期怎麼去管理，這一切都是跟PHP自己基本原理相關的，配置很簡單，理解有點困難，必定要把原理搞清楚）

5、PHP源碼目錄結構

PHP的源碼在結構上很是清晰。其代碼根目錄中主要包含了一些說明文件以及設計方案，並提供了以下子目錄：

一、build —— 顧名思義，這裏主要放置一些跟源碼編譯相關的文件，好比開始構建以前的buildconf腳本及一些檢查環境的腳本等。

二、ext —— 官方的擴展目錄，包括了絕大多數PHP的函數的定義和實現，如array系列，pdo系列，spl系列等函數的實現。 我的開發的擴展在測試時也能夠放到這個目錄，以方便測試等。（PHP支持衆多的擴展，如PHP可以使用一些加密庫處理用戶數據的時候進行加密等等）

三、main —— 這裏存放的就是PHP最爲核心的文件了，是實現PHP的基礎設施，這裏和Zend引擎不同，Zend引擎主要實現語言最核心的語言運行環境。

四、Zend —— Zend引擎的實現目錄，好比腳本的詞法語法解析，opcode的執行以及擴展機制的實現等等。

五、pear —— PHP 擴展與應用倉庫，包含PEAR的核心文件。

六、sapi —— 包含了各類服務器抽象層的代碼，例如apache的mod_php，cgi，fastcgi以及fpm等等接口。

七、TSRM —— PHP的線程安全是構建在TSRM庫之上的，PHP實現中常見的*G宏一般是對TSRM的封裝，TSRM(Thread Safe Resource Manager)線程安全資源管理器。

八、tests —— PHP的測試腳本集合，包含PHP各項功能的測試文件。

九、win32 —— 這個目錄主要包括Windows平臺相關的一些實現，好比sokcet的實如今Windows下和*Nix平臺就不太同樣，同時也包括了Windows下編譯PHP相關的腳本。

 

PHP理論基礎及相關配置

PHP官方站點：www.php.net

　　下載源程序後，須要解壓、編譯才能運行，PHP雖然是一種解釋型語言，但PHP自己確實須要編譯才能運行的程序，就像bash同樣，bash開發的腳本都是腳本，但bash自己確是二進制程序。

 

　　PHP既然是可以開發webapp的一種開發語言，這種語言只有在PHP的解釋器中須要zend Engine編譯後才能執行，但編譯結果如何可以跟Apache的服務器結合起來？

CGI：Common Gateway Interface，通用網關接口，讓Web服務器可以跟後端程序相結合的，調用後端程序執行應用程序的一種接口（協議）。

    PHP也是一種動態開發語言，那Web服務器Apache也僅僅是可以提供靜態HTML文檔或者其餘靜態文件，像圖形、圖片、MP3等靜態文件的一種服務器，若是說要想執行PHP程序的話，Apache自身是不能執行PHP程序的，要想執行PHP腳本須要PHP解釋器，那Apache進程與解釋器之間如何創建關聯關係？

 

    若Apache模塊正在運行，忽然間發現用戶訪問的是一個PHP頁面如1.php，他發現這須要用PHP處理器處理，因而它經過CGI這種機制去調用PHP解釋器去解釋執行這段代碼而且將解釋的執行以後的代碼返回給Apache，由Apache將這個返回的內容直接響應給客戶端了。

　　須要注意的是，用戶請求的必定是Web服務器對象，這個對象要麼是一個純文本文件、圖片、甚至視頻等，但用戶請求的是PHP文檔，這個文檔是程序，這個程序須要執行，執行後的結果是什麼？執行後的結果是一段數據流，Apache直接將這個數據流響應給客戶端了，由於Apache自身不須要將數據流保存成數據文件，何況就算請求的是靜態文件，這個文件保存在磁盤上，這個文件要被Apache訪問，它最後一樣要轉換成數據流（0、1代碼），數據流要經過網線發給客戶端。由此，既然PHP解釋器直接返回的是數據流，Apache直接把數據流響應給客戶端便可。

　　對於一個網頁文件（HTML）而言是有格式的，如：

　　可是寫一個bash腳本test.sh，內容以下：

　　這個程序的執行結果並非HTML格式的文檔，所以瀏覽器最後顯示爲純文本了。但這些純文本信息的顯示對用戶體驗並不友好。由此應該以HTML格式顯示給用戶。如何可以爲純文本生成HTML格式的標籤呢？

 

　　從上圖可看出當前Apache是支持cgi的。

　　而若要支持CGI還須要找到另一個指令：ScriptAlias，用來定義在哪一個目錄中執行腳本的：

　　　　/cgi-bin/：訪問路徑（URL或Alias）；

　　　　/var/www/cgi-bin/:訪問的目錄；

　　所以到/var/www/cgi-bin/目錄下寫一個腳本：

　　　　從上圖能夠看出，直接訪問這個腳本，沒法執行，由於Apache理解不了這個腳本。

　　　　再看test.sh：

　　這個腳本是能夠執行的。

　　修改：

　　因此腳本自身所處理的數據的結果，這個數據自己都是純ASCII碼，它是一些純文本流，這些純文本流應該格式化成在網頁上顯示起來更方便查看的HTML格式的文檔。

可是當之後代碼修改時，對應的由標籤組成的架構也須要修改，這是很是麻煩的，所以須要將數據處理的邏輯與框架分離，最後經過某種方式將它們拼合起來，這種機制稱爲MVC，也能夠叫作嵌入式開發語言。

推薦書籍：《大話設計模式》

 

那麼Web服務器如何與PHP交互？

    基於CGI的模式，Apache進程若是發現客戶端訪問了PHP頁面，它會調用PHP解釋器解釋器執行這段程序，既然是執行代碼的程序就會啓動一個進程生成一個新進程，一旦執行結束之後這個進程即被銷燬。但若是用戶訪問的程序既有1.php又有2.php，3.php，它是開三個進程，仍是一個進程訪問3個頁面呢？假如1調用2，2調用3，只須要一個進程便可，但若是說各自獨立調用須要啓動3個進程，這些進程何時啓動何時結束由CGI控制，所以PHP解釋器進程生命週期的管理也是由Apache管理的。

　　更重要的是，假如web服務器裏面的衆多的都是PHP頁面，如200個PHP頁面，3000靜態內容（static content），若基於prefork模型，試想200個請求同時來訪問PHP頁面的時候（假設請求同時到達，不考慮靜態），當前服務器上應該運行多少個進程呢？至少是400個，由於每個PHP也須要啓動一個進程，因此基於這種模式進行處理的時候會發現它運行的進程會超出想象，若一個Apache進程須要2M，而一個PHP進程的大小則取決於數據和程序了，假如處理的數據比較大，一個進程10M，20M，50M都有可能，而http是一種無狀態的協議（stateless），因此每個請求都是獨立創建的，假如咱們尚未使用長鏈接，隨時在線訪問的進程都有200個那就意味着頻繁的建立與銷燬進程系統開銷是很是大的，系統性能會顯著下降的。

　　因此對於PHP來說，CGI這種機制並非一種優良的機制，對於大量用戶併發來說尤爲如此。所以將Web進程與CGI進程合二爲一就簡單多了，那麼如何合二爲一呢？Apache支持DSO（Dynamic Share Object，動態共享對象）機制，Apache有衆多模塊使用load moduling加載進來，不加載就不支持這個功能，要想使用這個功能加載進來就能夠了。事實上，徹底能夠實現將PHP作成Apache的一個動態共享模塊的，將PHP編譯成php_mod，當Apache用到時，直接將這個模塊裝載進來去解釋PHP的內容便可。這也就意味着，在Apache進程內部就能本身裝載進這個模塊來完成對於PHP頁面的加載而且可以將加載生成的結果不用再進行進程間通訊，直接轉交給前端的處理程序便可。因此就使得就算有200個進程同時訪問，也只須要啓動200個進程處理便可。但有一缺陷就是Apache進程既要處理靜態內容又要處理動態內容，雖然已經大大簡化了cgi這種模式所具備的缺陷，但依然有着性能上的缺陷，尤爲是200個用戶而服務器最多容許250個請求同時進來，而假如說在峯值的併發時刻，已經有400個用戶同時到來了，服務器不能應付全部狀況了。此時就須要在加一臺服務器了，並且基於Nginx兩臺A記錄作負載均衡，用戶的請求有的到第一個服務器上，有的到第二個服務器上，這樣就簡單許多了。但進程自己須要處理動態和靜態內容，進程自己的過程會很複雜，使得整個服務器的改進會變得很是困難，由此就有了第三種讓PHP和Apache結合的模式，就是讓Apache的靜態內容處理和動態內容處理相分離。雖然這同CGI同樣，是使用不一樣的進程完成的，但不一樣的是CGI是在用戶請求時由Apache臨時建立CGI進程的。由此咱們能夠安裝一個PHP服務器，自身能夠向Apache的prefork同樣，事先生成不少空閒進程，不須要Apache管理，何時銷燬這個進程、何時生成這個進程，由這個服務器自我管理。前端的Apache進程須要用到PHP功能了，只須要向服務器發送請求，服務器找一個空閒進程分配給它響應便可，當分配給Apache的進程執行結束，這個進程被服務器收回來，由服務器自我管理銷燬，此時Apache或後端服務器的通訊就再也不是CGI了。能夠理解成是基於另一種獨立的服務器客戶端之間的協議，這個時候Apache服務器是客戶端，PHP是服務器，這種機制稱爲FastCGI。相似於剛纔解釋的這種機制，在PHP5.4中已經自帶了這種功能，叫fpm（fast php module，快速功能模塊）。

 

apache跟PHP結合的方式：

   CGI

   Module（最簡單的方式）

   FastCGI（當然性能比較好，但配置較麻煩）

 

 

注意：若Apache僅提供靜態功能的話，Nginx性能（處理靜態內容時）則比Apache好的多，因此使用fastcgi時一般使用Nginx+fpm。有些時候可能須要依賴於Apache某些模塊，此時就須要使用Apache了。

 

配置Web服務器使用PHP的功能

 

　　　　（php5.3.3不支持fpm，php5.3.4才支持）

 

 

 

 

 

 

 

　　　　php-mbstring：（Multi Byte）對國際化的支持

查看安裝php生成的功能：

    Apache基於prefork或worker模型時，它們所依賴php的模塊是不一樣的。

    AddHandler：添加一個處理器，如果一個以.php結尾的文件的話，就使用php5-script工具處理。php5-script這是Apache內置的一種處理機制，可以實如今內部完成怎麼去識別這種文件的。

    AddType：添加類別，text/html，多媒體類型，能將.php識別成純文本格式，固然須要先執行的。

    DirectoryIndex：定義默認的主頁面；

    phpinfo();　　#php內置函數，可以以Web頁面的方式顯示服務器內部信息；

php配置文件：/etc/php.ini

　　配置文件格式如：

　　每一段的標識的配置只對對應段生效，稱爲分段式的配置。由於php的模塊不少，每個模塊使用的指令可能都不同，因此分爲全局的，對每個模塊都生效的，還有局部的，對每個特定模塊生效的。

　　注意：.ini配置文件使用";"做爲註釋符；

 

　　由此，php就能直接工做了!!!