本文先介紹一下各種WEB伺服器平臺，然後對影響WEB伺服器效能的各方面做了分析，最後解析了目前使用最普遍的Apache伺服器在服務請求高峰時的響應延遲現象

　　在上週的一篇文章裡，我們介紹了搭建WEB伺服器的方法，但這只是建立WEB伺服器的第一步，在實際的站點執行中，也許伺服器的效能表現會不盡如人意，這就需要分析具體的伺服器效能瓶頸並找到解決辦法。本文先介紹一下各種WEB伺服器平臺，然後對影響WEB伺服器效能的各方面做了分析，最後解析了目前使用最普遍的Apache伺服器在服務請求高峰時的響應延遲現象，希望能對WEB伺服器效能瓶頸的分析有所幫助。
　　


　　對於網際網路上的web平臺，究竟有多少種不同的軟硬體組合方式？你肯定會對這個數字感到吃驚。從配置了最新版本的IIS（Internet Information Server，因特網資訊伺服器）的WindowsXP系統到執行在Apache伺服器上“古老”的SunOS 4.x系統，真是數之不盡。當然，最流行的幾種平臺也就那麼幾種。Windows NT類（尤其是同時配置了IIS和SQL Server的系統）是近來很常見的web平臺。同時，執行在SUN公司SPARC工作站上的Solaris（安裝了Netscape公司企業版的Webserver）和免費的Apache伺服器系統也比較常見。此外，令人相當吃驚的是，Linux和FreeBSD這兩款開放原始碼的頂級作業系統對上述幾類平臺構成了巨大的威脅。正在改變伺服器作業系統的分佈格局。

為什麼很多人選擇Windows NT/2000/XP？

　　先撇開卓越的執行穩定性、系統正常穩定執行時間或表現等不論，Windows NT類作業系統在伺服器應用環境領域佔據的市場份額以驚人的速度持續快速增長，原因主要是，它具有非常體貼使用者的易操作性及出類拔萃的開發工具。

　　很多剛進入IT領域的使用者非常喜歡Windows的這種“平民化”的介面，因為它極大地簡化了日常的管理工作。對於開發人員來說，則因Microsoft提供的目前最完整、最有效率的開發環境，而從NT系統中獲益不小。類似InterDev的一些開發工具與Visual Source Safe（在龐大的工程中對軟體版本進行管理）結合使用，能輕鬆地削減開發人員的開發時間。

為什麼有的人不選擇Windows NT？

　　Windows NT畢竟仍屬Windows家族的一員，也存在眾多該系列作業系統所遭遇的問題，從而影響到一些運算量大、資源消耗多的應用程式的穩定性和可執行性。Windows NT 4採用的是一個靜態的核心，這就使得即使是執行一些非常簡單的任務，比如裝載一個新的驅動器，也必須重啟機器。此外，和UNIX 相較而言，Windows NT還缺少大量的遠端管理手段。不過,隨著微軟新版的伺服器作業系統2000/XP的釋出,這些問題正在得到解決,最新的WindwoXP伺服器版可以說是一個不錯的伺服器作業系統。
　　
關於Solaris

　　Solaris是UNIX作業系統在市場上最流行的一種變體。網際網路上大部分站點都採用Solaris提供web服務。在UNIX所有不同的變體中，Solaris擁有最大的使用者群體，相應地，它也是利潤最豐厚的一款軟體。各種應用伺服器和應用環境專為Solaris設計的版本，比如ColdFusion（普遍使用在Windows NT上）均已推出。Solaris系統能夠提供真實的企業級可靠性和高效能，其他平臺很難與之媲美。與Windows NT不同的是，當你給系統新增額外的硬碟時，並不需要將Solaris系統重啟。另外，在Sun公司更大型的企業級伺服器上，你甚至能夠在不關機的情況下，更換記憶體條和CPU。與眾多平臺相比，Solaris還能提供最佳的多重處理（multiprocessing）效能。

為什麼有人不願意選擇Solaris？
　　
　　好了，為了公平起見，我來說說人們不選擇Solaris的原因。先要指出的是，基於Intel晶片的Solaris平臺不等同基於SPARC晶片的Solaris平臺。儘管Intel晶片版本的Solaris系統擁有與SPARC晶片版本一樣的高可靠性，但用於前者的商用軟體的數量明顯不如後者多，同時，由於硬體上的一些限制，Solaris系統的一些相對高階的特性（比如CPU或記憶體的熱插拔升級）在Intel晶片版本中無法實現。前段時間甚至有訊息說最新的Solaris將不再支援Intel平臺，這對採用Intel硬體平臺的使用者可說是一種遺憾。

選擇Linux還是FressBSD？

　　開放原始碼作業系統(如Linux、FreeBSD)在市場上搶佔著越來越大的市場份額，人們對這類系統的總體接受程度也開始以驚人的速度增長。幾年前，只有少數幾家公司知道Linux到底是什麼，但是目前它已被業界幾乎每一個專業使用者所大力推崇。舉個例子，你可以在市場上買到更多的基於Linux平臺的商業軟體，如Oracle、Sybase等等。

　　同時，FreeBSD也取得了相當一部分商業支援，其中一些是由於Linux流行的原因而帶來的。很多大型網站，比如Yahoo，跑的都是FreeBSD平臺。FreeBSD和Linux之間的相容性問題很小。因此，我們會發現，這兩款作業系統的使用者群體將同步持續增長。

　　不幸的是，很多使用開放原始碼作業系統的使用者由於不希望繳納相關的成本費用，實際上在抵制使用Linux平臺上的商業軟體。從某個角度來看，彷彿是因為這些使用者由於習慣了Linux系統免費使用的做法，而不願意為伺服器的其他應用付費。從目前情況看，這已對市場產生了激冷效應。我估計，隨著越來越多基於該平臺的軟體釋出，這種情況將會更加惡化。

　　這主要是因為Linux作業系統大多是被小公司和個人所選用，而這類群體實際上根本買不起企業級的商業軟體。這種狀況只有在opensource作業系統的技術和市場成熟壯大起來，並被更多的大公司（他們往往擁有更大的需求）接納之後才會逐漸改變。

　　在網際網路上，對開放原始碼作業系統支援的呼聲很高，但是，人們對這類平臺學習和理解的難度比Windows，甚或是Solaris要大得多。另外，所有的這類軟體均處在一個快速發展的過程中。所以，你在尋找你需要的東西的時候，也許總會不經意地發現系統的一些小bug（錯誤的計算機程式程式碼或例行程式上的瑕疵）及不完整的軟體包。

　　對於那些WEB服務需求小，硬體資源緊張的小公司來說，他們一般更願意採用一款開放原始碼作業系統（而不採用商業解決方案）。而對於缺少經驗的公司來說，他們則傾向選擇安全可靠的Windows解決方案。那些對Web 釋出需求巨大，同時要求系統正常執行時間比率超過99%或以上的公司也許會選擇Solaris平臺。因為olaris的穩定性可以為滿足這種苛刻的執行要求提供更大保障。



　　一臺提供web釋出服務的伺服器與其他大多數的常規主機相比較，被更寬泛的負載狀態（load conditions）所影響。事實上，一個web站點裡能夠容納大量各種各樣的內容，即使是其中一個簡單的HTTP伺服器（軟體意義上的伺服器），其負載也遠遠超出了HTTP協議設計者當初所能預料的範圍。

　　實際上，目前的web站點能夠採用各種技術，包括靜態HTML、內嵌或伺服器解析的HTML（inline/server-parsed HTML）和CGI（Common Gateway Interface，公共閘道器介面），並以ODBC（Open Database Connectivity，開放式資料庫互接）實現資料庫的互連。這些不同的資料來源中有一部分非常普通，而其餘部分卻並非如此。不管如何，每一種資料來源均以其獨特的方式在web服務中發揮著作用。在決定你的站點到底適合採用哪種伺服器之前，你應該明確一下，你的需求究竟是什麼。

靜態HTML

　　這是網際網路上任何站點最基本的一種構成“元素”。儘管真正意義上完全採用靜態HTML來搭建的站點數量越來越少，但是，幾乎所有的站點均不同程度地採用了這種“元素”。靜態的HTML頁面嚴格地由標準的HTML標示語言構成，並不需要伺服器端即時運算生成。這意味著，對一個靜態HTML文件發出訪問請求後，伺服器端只是簡單地將該文件傳輸到客戶端。從伺服器執行的那個時間片來看，這個傳輸過程僅僅佔用了很小的CPU資源。為了提高靜態HTML的訪問效率，主要可以對以下幾個方面進行優化：網路頻寬、磁碟I/O以及cache(高速緩衝儲存器)。

伺服器解析的HTML

　　依靠伺服器解析的HTML頁面包括兩部分的程式碼，一是標準的HTML程式碼，二是伺服器端執行的程式碼（由第三方的處理程式或web伺服器自己在頁面傳輸到客戶端前對其進行解釋）。這種HTML頁面是CGI程式的升級版本（因為它的執行效率更高）。目前，內嵌的伺服器端擴充套件集，比如ASP、PHP3，甚或是普通的伺服器端支援的擴充套件集，已得到了非常普遍的使用。開發這種擴充套件集的目的是要使網站上的內容更生動活潑，更模組化，以利於維護。此外，伺服器解析文件改善了效能相對低下的客戶端工作模式，將客戶端的負載降低到最低程度，同時也降低了資料傳輸對頻寬的要求。很顯然，你要得到這一切，就必須付出金錢的代價。因為伺服器解析文件必須在其傳輸到客戶端前就通過伺服器來進行解釋，所以，你要給你的伺服器新增額外的CPU。

公共閘道器介面（CGI）

　　CGI使Web站點具有更佳的互動性和實用性。它可以用來收集使用者的輸入資料，允許執行外部程式以執行眾多與使用者輸入相關的任務以及輸出執行結果等，因此，應用CGI後，網際網路的用途被大大擴充了。但是，要使用CGI，就必須付出一定開銷。特別在CGI與直譯器（譬如PERL）配合使用時，CGI的呼叫成本會很高。如果您的系統執行在極端繁重的負載條件下，該成本更是高居不下。如果可能的話，您應該考慮選用ASP或PHP3來取代CGI。

資料庫的互連性

　　目前，網際網路上最大的資源殺手當非線上資料庫（online databases）和電子商務（e-commerce）等應用莫屬。提供web功能的資料庫和應用伺服器近年來飛速增長，顯示出強勁的發展勢頭。從效能的角度來看，線上資料庫（基於Oracle、 SQL Server或 Sybase等）及應用如日中升，迫使人們更加關注伺服器的效能狀況。對於大型網站來說，高負載的HTTP傳輸和資料庫處理事務互相搶佔資源，並最終可能導致伺服器在極短的時間內崩潰或者變得慢如蝸牛。在這種情況下，推薦您使用專門的後臺執行的資料庫伺服器（當然也是出於安全的考慮）以及前臺處理的HTTP伺服器。



　　眾所周知，究竟選用哪種不同型別的傳輸介質，必須根據預期的負載型別來決定。因此，從這點來看，你應該可以粗略地決定究竟需要採用哪種硬體。儘管不同的平臺提供不同的效能水平，各個平臺的效能之間還是存在一定交迭的，因此，你可以在對需要採用多少數量的硬體作任何決定之前，初步選擇一下那些你使用起來最覺舒適的平臺。

　　下文將那些與特定網站（這類網站一般只採用標準的傳輸介質和內容型別，如靜態HTML、伺服器解析文件以及從少量到數量適中的CGI程式）相關聯的瓶頸根據其對系統的影響程度逐個列出。

　　網路頻寬

　　吞吐量及高峰傳輸速率或突發傳輸速率（Spikes/Burst Transfer Rates）

　　記憶體

　　Webserver客戶端和檔案系統緩衝區（Filesystem Cache）佔用的活動記憶體

　　儲存

　　訪問時間，跨多硬碟訪問的效率

　　中央處理器

　　在多程序或多執行緒環境下的效能

　　網路頻寬

　　可用的頻寬對於那些主要由靜態頁面構成的站點來說，也許是最關鍵的因素，但問題往往並不如你想象的那麼簡單。撇開網路的吞吐總量以及響應速度不講，在高負載的環境下，系統的突發傳輸速率是非常重要的。儘管通過單一的T1或T3傳輸速率提供的總頻寬對一個特定的站點而言也許綽綽有餘，但其最大的傳輸速率（T1下為1.5mbit/s，T3下為4.5mbit/s）也可能不足以應付系統的高峰傳輸負載。在使用者訪問的高峰期，某些站點也許根本無法訪問。這樣的站點在使用者企圖訪問它時顯得慢如蝸牛，而伺服器自身卻仍舊非常空閒。這樣看來，要成功搭建一個web主機，考慮清楚你到底需要多大的頻寬顯然是非常重要的。

　　記憶體

　　可用的實體記憶體是另外一個重要因素，這是因為對記憶體的佔用率會直接隨著對伺服器請求數量的增加而增加。計算分配給每個併發使用者的記憶體數量以及併發使用者的平均數量，只是你要考慮的事情中的一部分。檔案緩衝區也是非常重要的，因為它能將磁碟的使用頻率降到最低程度，明顯加快事務處理的總體速度。

　　對記憶體的需求很大程度上取決於使用在特定伺服器上的軟體的具體情況。除了作業系統的管理能力和檔案系統的緩衝區大小之外，你還需要將你所選擇的web伺服器軟體對硬體的特殊要求調查清楚。

　　儲存

　　和儲存介質有關的讀寫時間指標也是非常重要的，對大型檔案庫和資料庫（檔案緩衝區的作用在這明顯削弱）而言，尤其如此。在多裝置協同工作的條件下，Web伺服器的磁碟系統必須有卓越的效能，推薦採用SCSI硬碟或RAID陣列。對於那些主要放開了“只讀”許可權的站點（使用者不能上傳資料），RAID是最佳的解決方案。這是因為，在RAID陣列中存在多個硬碟磁頭，能明顯提升讀取操作的資料吞吐量。

　　中央處理器

　　對於那些主要由靜態頁面構成的站點來說，CPU只是你需要考慮的最次要的一個因素。這是因為，即便是一個非常低端的PC電腦也能充分發掘T1通道的傳輸速率。但是，在使用了包括CGI、伺服器解析文件或提供web訪問方式的資料庫的情況下，你需要更多地關注CPU的效能。在這種場合下，將事務處理速度和併發處理效能兩個概念分清楚是很重要的。如果你需要向一個較小的使用者群體提供某種對CPU依賴很大的應用服務，那麼，一個高速的單CPU可能是最有用的。但是，如果存在多個使用者同時對大批量的頁面提出訪問請求，那麼在這種情況下（尤其在這些頁面均以獨立的程序或執行緒模式開啟情況下），多CPU系統（即使這些CPU的速度都很慢）也許更為管用。

分析伺服器的工作模式

　　儘管在市場上可以購買到各式各樣的Web伺服器，但如果單就併發訪問的處理方式來看，所有的伺服器大體可以分成基本的四類。

　　Single-threaded模式（單執行緒模式）

　　非常有效，可充分提高資源效率（對稱多處理機除外）

　　Fork模式（分叉模式）

　　每個請求的成本高，效能差，有良好的對稱多處理特性

　　Pre-Fork模式（預分叉模式）

　　良好的對稱多處理特性，響應速度通常比較快

　　Threaded模式（執行緒模式）

　　效率高的多處理特性，響應快　　

　　Single-Threaded模式

　　single-threaded伺服器通常採用選擇的方法在單個程序中處理所有的訪問請求。對只配置了一個處理器的機器來說，這類伺服器是非常高效的。但是，它並不能通過增加額外的處理器來相應地提升效能。

　　在這次模擬測試中，我們在y軸標註的請求數量最大值為100條/秒，這是為了方便評估single-threaded模式下的效能。模擬的伺服器每秒處理的請求數量維持在70條，即便如此，這已和實際使用情況非常相近。我們發現，在該環境下，當處理較輕的負載時，single-threaded模式是非常高效的，響應速度也非常迅捷。隨著負載的增加，我們又發現，伺服器的效能表現每況愈下，這種狀況只能通過搭配更好的硬體才能改善。

　　Fork模式

　　通常來說，通過追加程序來處理每個請求的伺服器由於多了一個增加新程序的環節，效率比較低下，響應速度也比較慢。由於通過這種方式在應付大批量的客戶端請求時會過多地消耗資源，顯然，隨著請求數量和頻率的增加，系統的效能將逐步下降。
　　
　　fork模式下的測試結果和single-threaded模式下的測試結果非常相似。不同的是，由於每一個新程序的成本較高，相對於single-threaded伺服器來說，這種模式下的管理維護成本會隨著http伺服器程序的增加而增加。

　　Pre-Fork模式

　　pre-fork伺服器和fork伺服器相似，也是通過一個單獨的程序來處理每條請求。但是，不同的是，pre-fork伺服器會通過預先開啟大量的程序，等待並處理接到的請求。由於採用了這種方式來開啟程序，伺服器並不需要等待新的程序啟動而消耗時間，因而能夠以更快的速度應付多使用者請求。另外，pre-fork伺服器在遇到極大的高峰負載時仍能保持良好的效能狀態。這是因為不管什麼時候，只要預先設定的所有程序都已被用來處理請求時，伺服器仍可追加額外的程序。

　　pre-fork伺服器相當獨特的執行狀態曲線。和先前提到的fork模式類似的是，pre-fork伺服器也是通過獨立的http伺服器程序來處理每一個請求，但是，和fork伺服器不同的是，pre-fork伺服器會隨著請求數量的增加而啟動若干新的程序。這種方法的優點是，能在對http通訊保持一定響應能力的同時，給伺服器提供少許的“喘息”時間。缺點是，當遇到高峰負載時，由於要啟動新的伺服器程序，不可避免地會帶來響應的延遲。

　　Threaded模式

　　threaded伺服器和http伺服器（對每一請求都必須生成新的程序來處理）有些類似。但是，它由於採用了執行緒技術，一般能以更低的管理成本取得用程序來處理請求的效果。
　　
　　threaded伺服器和通過生成新的程序來處理請求的伺服器差別不大，只是它生成的是執行緒而不是程序，因此，它對資源的依賴性也比較小。



　　目前世界上最流行的Web伺服器非Apache莫屬。它採用的是Pre-Fork模式。讓我們看看它是怎麼工作的。

　　Apache的Pre-Fork伺服器設計的原理是：當閒置的伺服器程序數量小於使用者預設的閥值時就啟動額外的程序。另一使用者設定的變數則決定空閒的伺服器程序的最大數量，同時，如果實際閒置的程序數量超過這個最大值，伺服器就會將空閒的程序關閉。

　　為了順利完成以下的模擬測試，我們先假定以下幾個條件：

　　1、空閒的伺服器程序數量的最小值為5

　　2、空閒的伺服器程序數量的最大值為10

　　3、伺服器程序數量的初始值為5
　　
　　當Pre-Fork伺服器在一個“無限機”上的執行狀態（這臺機器擁有無窮大的實體記憶體和CPU時間，我們姑且假定它是真實存在的）。Pre-Fork 伺服器在遇到高峰負載時產生的“步階”（stair-step）效應。實際上，在這種情況下，由於之前假定Pre-Fork伺服器擁有無限的資源，所以它的效能表現非常令人滿意。但是，隨著時間的推移，實際效能卻能通過修改基於平均負載活動的伺服器程序數量的最大和最小值而發生變化。

　　當然，這臺擁有無限資源的機器顯然是不存在的，因此，讓我們在做一個比較真實一些的模擬測試。這次，我們要把實體記憶體的使用情況考慮進去。姑且作以下假定：

　　1、空閒的伺服器程序數量的最小值為5

　　2、空閒的伺服器程序數量的最大值為10

　　3、伺服器程序數量的初始值為5

　　4、這臺機器配置了256 MB的實體記憶體。將作業系統和檔案系統緩衝區因素考慮進去的話，我們假定其中有196MB的記憶體單獨供web伺服器使用。

　　5、每一web伺服器程序消耗1.5 MB的實體記憶體

　　6、不考慮CPU和硬碟因素，同時，我們假定一旦機器的記憶體耗竭，就無法再處理額外的訪問請求。

　　這次測試表明，在機器所有實體記憶體被龐大的高峰負載消耗殆盡之前，我們這臺更真實的伺服器的效能表現和那臺擁有無限資源的理想伺服器是完全一樣的。可用的實體記憶體數量（單位：MB）用紅線在圖中標示，併發請求數量達到130條時，記憶體就被耗光。這使得320個請求處於未響應狀態。如果我們將CPU的使用率和磁碟活動等因素考慮進去的話，這些數字將會更小，機器為應付缺少可用記憶體的狀況而忙於將資料在記憶體與硬碟之間交換，這顯然會降低系統的效能。
　　


　　正如你所知道的，影響web伺服器效能的因素數之不盡，要限制這些因素髮揮作用，只能充分發揮人們的創造性思維。用來發布不同型別頁面的Web系統對硬體的要求也是不一樣的。本文只是粗略地介紹了搭建一個Web伺服器要考慮的因素，我希望它能幫助你更好地去理解這些系統要求。在這個基礎之上，今後，我們還將發表一些文章，介紹一下在Web伺服器環境下的Athlon系統、對稱多處理（SMP）系統以及它們在Web環境下的效能表現。