轉(zhuǎn)自：http://www.it./PcTech-34683.html 

本文先介紹一下各種WEB服務(wù)器平臺，然后對影響WEB服務(wù)器性能的各方面做了分析，最后解析了目前使用最普遍的Apache服務(wù)器在服務(wù)請求高峰時的響應(yīng)延遲現(xiàn)象 

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


　　對于互聯(lián)網(wǎng)上的web平臺，究竟有多少種不同的軟硬件組合方式？你肯定會對這個數(shù)字感到吃驚。從配置了最新版本的IIS（Internet Information Server，因特網(wǎng)信息服務(wù)器）的WindowsXP系統(tǒng)到運行在Apache服務(wù)器上“古老”的SunOS 4.x系統(tǒng)，真是數(shù)之不盡。當(dāng)然，最流行的幾種平臺也就那么幾種。Windows NT類（尤其是同時配置了IIS和SQL Server的系統(tǒng)）是近來很常見的web平臺。同時，運行在SUN公司SPARC工作站上的Solaris（安裝了Netscape公司企業(yè)版的 Webserver）和免費的Apache服務(wù)器系統(tǒng)也比較常見。此外，令人相當(dāng)吃驚的是，Linux和FreeBSD這兩款開放源代碼的頂級操作系統(tǒng)對 上述幾類平臺構(gòu)成了巨大的威脅。正在改變服務(wù)器操作系統(tǒng)的分布格局。 

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

　　先撇開卓越的運行穩(wěn)定性、系統(tǒng)正常穩(wěn)定運行時間或表現(xiàn)等不論，Windows NT類操作系統(tǒng)在服務(wù)器應(yīng)用環(huán)境領(lǐng)域占據(jù)的市場份額以驚人的速度持續(xù)快速增長，原因主要是，它具有非常體貼用戶的易操作性及出類拔萃的開發(fā)工具。 

　　很多剛進(jìn)入IT領(lǐng)域的用戶非常喜歡Windows的這種“平民化”的界面，因為它極大地簡化了日常的管理工作。對于開發(fā)人員來說，則因 Microsoft提供的目前最完整、最有效率的開發(fā)環(huán)境，而從NT系統(tǒng)中獲益不小。類似InterDev的一些開發(fā)工具與Visual Source Safe（在龐大的工程中對軟件版本進(jìn)行管理）結(jié)合使用，能輕松地削減開發(fā)人員的開發(fā)時間。 

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

　　Windows NT畢竟仍屬Windows家族的一員，也存在眾多該系列操作系統(tǒng)所遭遇的問題，從而影響到一些運算量大、資源消耗多的應(yīng)用程序的穩(wěn)定性和可執(zhí)行性。 Windows NT 4采用的是一個靜態(tài)的內(nèi)核，這就使得即使是執(zhí)行一些非常簡單的任務(wù)，比如裝載一個新的驅(qū)動器，也必須重啟機(jī)器。此外，和UNIX 相較而言，Windows NT還缺少大量的遠(yuǎn)程管理手段。不過,隨著微軟新版的服務(wù)器操作系統(tǒng)2000/XP的發(fā)布,這些問題正在得到解決,最新的WindwoXP服務(wù)器版可以說 是一個不錯的服務(wù)器操作系統(tǒng)。 
　　 
關(guān)于Solaris 

　　Solaris是UNIX操作系統(tǒng)在市場上最流行的一種變體?；ヂ?lián)網(wǎng)上大部分站點都采用Solaris提供web服務(wù)。在UNIX所有不同的 變體中，Solaris擁有最大的用戶群體，相應(yīng)地，它也是利潤最豐厚的一款軟件。各種應(yīng)用服務(wù)器和應(yīng)用環(huán)境專為Solaris設(shè)計的版本，比如 ColdFusion（普遍使用在Windows NT上）均已推出。Solaris系統(tǒng)能夠提供真實的企業(yè)級可靠性和高性能，其他平臺很難與之媲美。與Windows NT不同的是，當(dāng)你給系統(tǒng)添加額外的硬盤時，并不需要將Solaris系統(tǒng)重啟。另外，在Sun公司更大型的企業(yè)級服務(wù)器上，你甚至能夠在不關(guān)機(jī)的情況 下，更換內(nèi)存條和CPU。與眾多平臺相比，Solaris還能提供最佳的多重處理（multiprocessing）性能。 

為什么有人不愿意選擇Solaris？ 
　　 
　　好了，為了公平起見，我來說說人們不選擇Solaris的原因。先要指出的是，基于Intel芯片的Solaris平臺不等同基于SPARC 芯片的Solaris平臺。盡管Intel芯片版本的Solaris系統(tǒng)擁有與SPARC芯片版本一樣的高可靠性，但用于前者的商用軟件的數(shù)量明顯不如后 者多，同時，由于硬件上的一些限制，Solaris系統(tǒng)的一些相對高級的特性（比如CPU或內(nèi)存的熱插拔升級）在Intel芯片版本中無法實現(xiàn)。前段時間 甚至有消息說最新的Solaris將不再支持Intel平臺，這對采用Intel硬件平臺的用戶可說是一種遺憾。 

選擇Linux還是FressBSD？ 

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

　　同時，F(xiàn)reeBSD也取得了相當(dāng)一部分商業(yè)支持，其中一些是由于Linux流行的原因而帶來的。很多大型網(wǎng)站，比如Yahoo，跑的都是 FreeBSD平臺。FreeBSD和Linux之間的兼容性問題很小。因此，我們會發(fā)現(xiàn)，這兩款操作系統(tǒng)的用戶群體將同步持續(xù)增長。 

　　不幸的是，很多使用開放源代碼操作系統(tǒng)的用戶由于不希望繳納相關(guān)的成本費用，實際上在抵制使用Linux平臺上的商業(yè)軟件。從某個角度來看， 仿佛是因為這些用戶由于習(xí)慣了Linux系統(tǒng)免費使用的做法，而不愿意為服務(wù)器的其他應(yīng)用付費。從目前情況看，這已對市場產(chǎn)生了激冷效應(yīng)。我估計，隨著越 來越多基于該平臺的軟件發(fā)布，這種情況將會更加惡化。 

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

　　在互聯(lián)網(wǎng)上，對開放源碼操作系統(tǒng)支持的呼聲很高，但是，人們對這類平臺學(xué)習(xí)和理解的難度比Windows，甚或是Solaris要大得多。另 外，所有的這類軟件均處在一個快速發(fā)展的過程中。所以，你在尋找你需要的東西的時候，也許總會不經(jīng)意地發(fā)現(xiàn)系統(tǒng)的一些小bug（錯誤的計算機(jī)程序代碼或例 行程序上的瑕疵）及不完整的軟件包。 

　　對于那些WEB服務(wù)需求小，硬件資源緊張的小公司來說，他們一般更愿意采用一款開放源碼操作系統(tǒng)（而不采用商業(yè)解決方案）。而對于缺少經(jīng)驗的 公司來說，他們則傾向選擇安全可靠的Windows解決方案。那些對Web 發(fā)布需求巨大，同時要求系統(tǒng)正常運行時間比率超過99%或以上的公司也許會選擇Solaris平臺。因為olaris的穩(wěn)定性可以為滿足這種苛刻的運行要 求提供更大保障。 



　　一臺提供web發(fā)布服務(wù)的服務(wù)器與其他大多數(shù)的常規(guī)主機(jī)相比較，被更寬泛的負(fù)載狀態(tài)（load conditions）所影響。事實上，一個web站點里能夠容納大量各種各樣的內(nèi)容，即使是其中一個簡單的HTTP服務(wù)器（軟件意義上的服務(wù)器），其負(fù) 載也遠(yuǎn)遠(yuǎn)超出了HTTP協(xié)議設(shè)計者當(dāng)初所能預(yù)料的范圍。 

　　實際上，目前的web站點能夠采用各種技術(shù)，包括靜態(tài)HTML、內(nèi)嵌或服務(wù)器解析的HTML（inline/server-parsed HTML）和CGI（Common Gateway Interface，公共網(wǎng)關(guān)接口），并以O(shè)DBC（Open Database Connectivity，開放式數(shù)據(jù)庫互接）實現(xiàn)數(shù)據(jù)庫的互連。這些不同的數(shù)據(jù)源中有一部分非常普通，而其余部分卻并非如此。不管如何，每一種數(shù)據(jù)源均 以其獨特的方式在web服務(wù)中發(fā)揮著作用。在決定你的站點到底適合采用哪種服務(wù)器之前，你應(yīng)該明確一下，你的需求究竟是什么。 

靜態(tài)HTML 

　　這是互聯(lián)網(wǎng)上任何站點最基本的一種構(gòu)成“元素”。盡管真正意義上完全采用靜態(tài)HTML來搭建的站點數(shù)量越來越少，但是，幾乎所有的站點均不同 程度地采用了這種“元素”。靜態(tài)的HTML頁面嚴(yán)格地由標(biāo)準(zhǔn)的HTML標(biāo)示語言構(gòu)成，并不需要服務(wù)器端即時運算生成。這意味著，對一個靜態(tài)HTML文檔發(fā) 出訪問請求后，服務(wù)器端只是簡單地將該文檔傳輸?shù)娇蛻舳恕姆?wù)器運行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。為了提高靜態(tài)HTML 的訪問效率，主要可以對以下幾個方面進(jìn)行優(yōu)化：網(wǎng)絡(luò)帶寬、磁盤I/O以及cache(高速緩沖存儲器)。 

服務(wù)器解析的HTML 

　　依靠服務(wù)器解析的HTML頁面包括兩部分的代碼，一是標(biāo)準(zhǔn)的HTML代碼，二是服務(wù)器端運行的代碼（由第三方的處理程序或web服務(wù)器自己在 頁面?zhèn)鬏數(shù)娇蛻舳饲皩ζ溥M(jìn)行解釋）。這種HTML頁面是CGI程序的升級版本（因為它的執(zhí)行效率更高）。目前，內(nèi)嵌的服務(wù)器端擴(kuò)展集，比如ASP、 PHP3，甚或是普通的服務(wù)器端支持的擴(kuò)展集，已得到了非常普遍的使用。開發(fā)這種擴(kuò)展集的目的是要使網(wǎng)站上的內(nèi)容更生動活潑，更模塊化，以利于維護(hù)。此 外，服務(wù)器解析文檔改善了性能相對低下的客戶端工作模式，將客戶端的負(fù)載降低到最低程度，同時也降低了數(shù)據(jù)傳輸對帶寬的要求。很顯然，你要得到這一切，就 必須付出金錢的代價。因為服務(wù)器解析文檔必須在其傳輸?shù)娇蛻舳饲熬屯ㄟ^服務(wù)器來進(jìn)行解釋，所以，你要給你的服務(wù)器添加額外的CPU。 

公共網(wǎng)關(guān)接口（CGI） 

　　CGI使Web站點具有更佳的交互性和實用性。它可以用來收集用戶的輸入數(shù)據(jù)，允許運行外部程序以執(zhí)行眾多與用戶輸入相關(guān)的任務(wù)以及輸出執(zhí)行 結(jié)果等，因此，應(yīng)用CGI后，互聯(lián)網(wǎng)的用途被大大擴(kuò)充了。但是，要使用CGI，就必須付出一定開銷。特別在CGI與解釋器（譬如PERL）配合使用 時，CGI的調(diào)用成本會很高。如果您的系統(tǒng)運行在極端繁重的負(fù)載條件下，該成本更是高居不下。如果可能的話，您應(yīng)該考慮選用ASP或PHP3來取代 CGI。 

數(shù)據(jù)庫的互連性 

　　目前，互聯(lián)網(wǎng)上最大的資源殺手當(dāng)非在線數(shù)據(jù)庫（online databases）和電子商務(wù)（e-commerce）等應(yīng)用莫屬。提供web功能的數(shù)據(jù)庫和應(yīng)用服務(wù)器近年來飛速增長，顯示出強(qiáng)勁的發(fā)展勢頭。從性能 的角度來看，在線數(shù)據(jù)庫（基于Oracle、 SQL Server或 Sybase等）及應(yīng)用如日中升，迫使人們更加關(guān)注服務(wù)器的性能狀況。對于大型網(wǎng)站來說，高負(fù)載的HTTP傳輸和數(shù)據(jù)庫處理事務(wù)互相搶占資源，并最終可能 導(dǎo)致服務(wù)器在極短的時間內(nèi)崩潰或者變得慢如蝸牛。在這種情況下，推薦您使用專門的后臺運行的數(shù)據(jù)庫服務(wù)器（當(dāng)然也是出于安全的考慮）以及前臺處理的 HTTP服務(wù)器。 



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

　　下文將那些與特定網(wǎng)站（這類網(wǎng)站一般只采用標(biāo)準(zhǔn)的傳輸介質(zhì)和內(nèi)容類型，如靜態(tài)HTML、服務(wù)器解析文檔以及從少量到數(shù)量適中的CGI程序）相關(guān)聯(lián)的瓶頸根據(jù)其對系統(tǒng)的影響程度逐個列出。 

　　網(wǎng)絡(luò)帶寬 

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

　　內(nèi)存 

　　Webserver客戶端和文件系統(tǒng)緩沖區(qū)（Filesystem Cache）占用的活動內(nèi)存 

　　存儲 

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

　　中央處理器 

　　在多進(jìn)程或多線程環(huán)境下的性能 

　　網(wǎng)絡(luò)帶寬 

　　可用的帶寬對于那些主要由靜態(tài)頁面構(gòu)成的站點來說，也許是最關(guān)鍵的因素，但問題往往并不如你想象的那么簡單。撇開網(wǎng)絡(luò)的吞吐總量以及響應(yīng)速度 不講，在高負(fù)載的環(huán)境下，系統(tǒng)的突發(fā)傳輸速率是非常重要的。盡管通過單一的T1或T3傳輸速率提供的總帶寬對一個特定的站點而言也許綽綽有余，但其最大的 傳輸速率（T1下為1.5mbit/s，T3下為4.5mbit/s）也可能不足以應(yīng)付系統(tǒng)的高峰傳輸負(fù)載。在用戶訪問的高峰期，某些站點也許根本無法訪 問。這樣的站點在用戶企圖訪問它時顯得慢如蝸牛，而服務(wù)器自身卻仍舊非?？臻e。這樣看來，要成功搭建一個web主機(jī)，考慮清楚你到底需要多大的帶寬顯然是 非常重要的。 

　　內(nèi)存 

　　可用的物理內(nèi)存是另外一個重要因素，這是因為對內(nèi)存的占用率會直接隨著對服務(wù)器請求數(shù)量的增加而增加。計算分配給每個并發(fā)用戶的內(nèi)存數(shù)量以及 并發(fā)用戶的平均數(shù)量，只是你要考慮的事情中的一部分。文件緩沖區(qū)也是非常重要的，因為它能將磁盤的使用頻率降到最低程度，明顯加快事務(wù)處理的總體速度。 

　　對內(nèi)存的需求很大程度上取決于使用在特定服務(wù)器上的軟件的具體情況。除了操作系統(tǒng)的管理能力和文件系統(tǒng)的緩沖區(qū)大小之外，你還需要將你所選擇的web服務(wù)器軟件對硬件的特殊要求調(diào)查清楚。 

　　存儲 

　　和存儲介質(zhì)有關(guān)的讀寫時間指標(biāo)也是非常重要的，對大型文件庫和數(shù)據(jù)庫（文件緩沖區(qū)的作用在這明顯削弱）而言，尤其如此。在多設(shè)備協(xié)同工作的條 件下，Web服務(wù)器的磁盤系統(tǒng)必須有卓越的性能，推薦采用SCSI硬盤或RAID陣列。對于那些主要放開了“只讀”權(quán)限的站點（用戶不能上傳數(shù) 據(jù)），RAID是最佳的解決方案。這是因為，在RAID陣列中存在多個硬盤磁頭，能明顯提升讀取操作的數(shù)據(jù)吞吐量。 

　　中央處理器 

　　對于那些主要由靜態(tài)頁面構(gòu)成的站點來說，CPU只是你需要考慮的最次要的一個因素。這是因為，即便是一個非常低端的PC電腦也能充分發(fā)掘T1 通道的傳輸速率。但是，在使用了包括CGI、服務(wù)器解析文檔或提供web訪問方式的數(shù)據(jù)庫的情況下，你需要更多地關(guān)注CPU的性能。在這種場合下，將事務(wù) 處理速度和并發(fā)處理性能兩個概念分清楚是很重要的。如果你需要向一個較小的用戶群體提供某種對CPU依賴很大的應(yīng)用服務(wù)，那么，一個高速的單CPU可能是 最有用的。但是，如果存在多個用戶同時對大批量的頁面提出訪問請求，那么在這種情況下（尤其在這些頁面均以獨立的進(jìn)程或線程模式打開情況下），多CPU系 統(tǒng)（即使這些CPU的速度都很慢）也許更為管用。 

分析服務(wù)器的工作模式 

　　盡管在市場上可以購買到各式各樣的Web服務(wù)器，但如果單就并發(fā)訪問的處理方式來看，所有的服務(wù)器大體可以分成基本的四類。 

　　Single-threaded模式（單線程模式） 

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

　　Fork模式（分叉模式） 

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

　　Pre-Fork模式（預(yù)分叉模式） 

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

　　Threaded模式（線程模式） 

　　效率高的多處理特性，響應(yīng)快　　 

　　Single-Threaded模式 

　　single-threaded服務(wù)器通常采用選擇的方法在單個進(jìn)程中處理所有的訪問請求。對只配置了一個處理器的機(jī)器來說，這類服務(wù)器是非常高效的。但是，它并不能通過增加額外的處理器來相應(yīng)地提升性能。 

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

　　Fork模式 

　　通常來說，通過追加進(jìn)程來處理每個請求的服務(wù)器由于多了一個增加新進(jìn)程的環(huán)節(jié)，效率比較低下，響應(yīng)速度也比較慢。由于通過這種方式在應(yīng)付大批量的客戶端請求時會過多地消耗資源，顯然，隨著請求數(shù)量和頻率的增加，系統(tǒng)的性能將逐步下降。 
　　 
　　fork模式下的測試結(jié)果和single-threaded模式下的測試結(jié)果非常相似。不同的是，由于每一個新進(jìn)程的成本較高，相對于single-threaded服務(wù)器來說，這種模式下的管理維護(hù)成本會隨著http服務(wù)器進(jìn)程的增加而增加。 

　　Pre-Fork模式 

　　pre-fork服務(wù)器和fork服務(wù)器相似，也是通過一個單獨的進(jìn)程來處理每條請求。但是，不同的是，pre-fork服務(wù)器會通過預(yù)先開 啟大量的進(jìn)程，等待并處理接到的請求。由于采用了這種方式來開啟進(jìn)程，服務(wù)器并不需要等待新的進(jìn)程啟動而消耗時間，因而能夠以更快的速度應(yīng)付多用戶請求。 另外，pre-fork服務(wù)器在遇到極大的高峰負(fù)載時仍能保持良好的性能狀態(tài)。這是因為不管什么時候，只要預(yù)先設(shè)定的所有進(jìn)程都已被用來處理請求時，服務(wù) 器仍可追加額外的進(jìn)程。 

　　pre-fork服務(wù)器相當(dāng)獨特的運行狀態(tài)曲線。和先前提到的fork模式類似的是，pre-fork服務(wù)器也是通過獨立的http服務(wù)器進(jìn) 程來處理每一個請求，但是，和fork服務(wù)器不同的是，pre-fork服務(wù)器會隨著請求數(shù)量的增加而啟動若干新的進(jìn)程。這種方法的優(yōu)點是，能在對 http通訊保持一定響應(yīng)能力的同時，給服務(wù)器提供少許的“喘息”時間。缺點是，當(dāng)遇到高峰負(fù)載時，由于要啟動新的服務(wù)器進(jìn)程，不可避免地會帶來響應(yīng)的延 遲。 

　　Threaded模式 

　　threaded服務(wù)器和http服務(wù)器（對每一請求都必須生成新的進(jìn)程來處理）有些類似。但是，它由于采用了線程技術(shù)，一般能以更低的管理成本取得用進(jìn)程來處理請求的效果。 
　　 
　　threaded服務(wù)器和通過生成新的進(jìn)程來處理請求的服務(wù)器差別不大，只是它生成的是線程而不是進(jìn)程，因此，它對資源的依賴性也比較小。 



　　目前世界上最流行的Web服務(wù)器非Apache莫屬。它采用的是Pre-Fork模式。讓我們看看它是怎么工作的。 

　　Apache的Pre-Fork服務(wù)器設(shè)計的原理是：當(dāng)閑置的服務(wù)器進(jìn)程數(shù)量小于用戶預(yù)設(shè)的閥值時就啟動額外的進(jìn)程。另一用戶設(shè)定的變量則決定空閑的服務(wù)器進(jìn)程的最大數(shù)量，同時，如果實際閑置的進(jìn)程數(shù)量超過這個最大值，服務(wù)器就會將空閑的進(jìn)程關(guān)閉。 

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

　　1、空閑的服務(wù)器進(jìn)程數(shù)量的最小值為5 

　　2、空閑的服務(wù)器進(jìn)程數(shù)量的最大值為10 

　　3、服務(wù)器進(jìn)程數(shù)量的初始值為5 
　　 
　　當(dāng)Pre-Fork服務(wù)器在一個“無限機(jī)”上的運行狀態(tài)（這臺機(jī)器擁有無窮大的物理內(nèi)存和CPU時間，我們姑且假定它是真實存在的）。 Pre-Fork 服務(wù)器在遇到高峰負(fù)載時產(chǎn)生的“步階”（stair-step）效應(yīng)。實際上，在這種情況下，由于之前假定Pre-Fork服務(wù)器擁有無限的資源，所以它 的性能表現(xiàn)非常令人滿意。但是，隨著時間的推移，實際性能卻能通過修改基于平均負(fù)載活動的服務(wù)器進(jìn)程數(shù)量的最大和最小值而發(fā)生變化。 

　　當(dāng)然，這臺擁有無限資源的機(jī)器顯然是不存在的，因此，讓我們在做一個比較真實一些的模擬測試。這次，我們要把物理內(nèi)存的使用情況考慮進(jìn)去。姑且作以下假定： 

　　1、空閑的服務(wù)器進(jìn)程數(shù)量的最小值為5 

　　2、空閑的服務(wù)器進(jìn)程數(shù)量的最大值為10 

　　3、服務(wù)器進(jìn)程數(shù)量的初始值為5 

　　4、這臺機(jī)器配置了256 MB的物理內(nèi)存。將操作系統(tǒng)和文件系統(tǒng)緩沖區(qū)因素考慮進(jìn)去的話，我們假定其中有196MB的內(nèi)存單獨供web服務(wù)器使用。 

　　5、每一web服務(wù)器進(jìn)程消耗1.5 MB的物理內(nèi)存 

　　6、不考慮CPU和硬盤因素，同時，我們假定一旦機(jī)器的內(nèi)存耗竭，就無法再處理額外的訪問請求。 

　　這次測試表明，在機(jī)器所有物理內(nèi)存被龐大的高峰負(fù)載消耗殆盡之前，我們這臺更真實的服務(wù)器的性能表現(xiàn)和那臺擁有無限資源的理想服務(wù)器是完全一 樣的?？捎玫奈锢韮?nèi)存數(shù)量（單位：MB）用紅線在圖中標(biāo)示，并發(fā)請求數(shù)量達(dá)到130條時，內(nèi)存就被耗光。這使得320個請求處于未響應(yīng)狀態(tài)。如果我們將 CPU的使用率和磁盤活動等因素考慮進(jìn)去的話，這些數(shù)字將會更小，機(jī)器為應(yīng)付缺少可用內(nèi)存的狀況而忙于將數(shù)據(jù)在內(nèi)存與硬盤之間交換，這顯然會降低系統(tǒng)的性 能。 
　　 


　　正如你所知道的，影響web服務(wù)器性能的因素數(shù)之不盡，要限制這些因素發(fā)揮作用，只能充分發(fā)揮人們的創(chuàng)造性思維。用來發(fā)布不同類型頁面的 Web系統(tǒng)對硬件的要求也是不一樣的。本文只是粗略地介紹了搭建一個Web服務(wù)器要考慮的因素，我希望它能幫助你更好地去理解這些系統(tǒng)要求。在這個基礎(chǔ)之 上，今后，我們還將發(fā)表一些文章，介紹一下在Web服務(wù)器環(huán)境下的Athlon系統(tǒng)、對稱多處理（SMP）系統(tǒng)以及它們在Web環(huán)境下的性能表現(xiàn)。