webserver/CGI
睿豐德科技 專注RFID識別技術和條碼識別技術與管理軟件的集成項目。質量追溯系統、MES系統、金蝶與條碼系統對接、用友與條碼系統對接
來自：http://blog.sina.com.cn/s/blog_466c6640010000nj.html
1. TUX
2. lighttpd,thttpd,shttpd
3. 幾種web server表現的對比
4. 我的總結 TUX
http://www.chinadesign.com.cn/NewsContents1.asp?id=3386
tux是一種有GPL（GNU General Public License ）許可的基于內核的Web服務器。 目前它還只能提供靜態的網頁服務，只有和內核區模塊，用戶區模塊，以及一般的用戶區Web服務器后臺一起應用的時候才提供動態的內容服務。一般用戶區的Web服務器不需要為了適應TUX而改變很多地方。然而，用戶區數據段代碼必須要有一個通向TUX的系統調用的接口。 雖然動態的內容服務現在增長的很迅速，但是也必須要提供靜態的內容服務。如，所有的圖片文件就都是靜態的。TUX能給在Linux的內核里提供非常高效率的靜態內容服務，就象在內核里運行的NFS網絡文件系統服務一樣。 TUX也有處理動態內容的功能。TUX模塊用網頁緩沖存儲動態內容的對象。當一個動態的請求到達的時候，一個TUX的模塊就發送會一個聯合 的動態請求并緩沖這個請求。這就是TUX的零拷貝緩存校驗的結構。（建議TUX模塊不許運行在用戶區，雖然他們也可以運行在內核區。） 這個新的動態內容的處理需要一個新的API接口。當前的CGI的API接口不能充分的用在TUX的API上。因此，當前的CGI程序為了使 用TUX就要修改當前的程序。如果CGI程序不需要增加TUX的速度的話，TUX也可以把它安一般的CGI來處理。要實現這個功能就要用TUX的CGI模 塊。TUX也可以處理復雜的CGI或是其他的請求，這要通過它把請求重定向到另外一個web服務器后臺程序，如Apache。也就是說，靜態的內 容，TUX模塊，老的CGI程序，以及為TUX Web服務器編寫的特定的程序都可以在TUX這個主服務器里運行。 一句話，TUX和其他的Web服務器的區別和TUX的好處包括： TUX是作為Linux的內核2.4.x或更高的一部分來運行的，另外一部分可以做為用戶區來運行。 TUX緩存部分的TCP校驗并用它們來加快網絡數據傳輸速度。 用一個特定的網絡卡，TUX可以從頁面緩存定向分散的DMA直接到網絡，這樣就避免了數據的拷貝。 當TUX不知道如何去處理一個請求或是接受到一個請求不能去運行的時候，它一般會把這個請求傳送到用戶區的Web服務器后臺去處理它。一個典型的用戶區Web服務器就是Apache。 2．TUX 2.0的新功能 TUX 2.0是從TUX 1.0升級成的，仍然保守著與用戶區模塊的兼容性。 增加的功能包括： 真正的零磁盤讀拷貝，TUX1.0是放到一個臨時的緩存里的。
生成網絡寫的零拷貝。
零拷貝解析。
其他新功能： 提高用戶去功能模塊的支持。
虛擬主機的支持，它不限制虛擬主機的數量。
CGI可以綁定到特定的進程
一些BUG的修復。 3．系統的基本需要 TUX需要基于2.4.x內核或是更高版本的系統。
基于X86的服務器。
交替的Web服務器如Apache來處理不知道的請求
當前的限制：
內核模塊只支持服務器端。
TUX只在x86的Linux平臺上測試過。
TUX能請求其他的Web服務器如Apache來處理請求。在當前的版本，它對回滾不是處理的很好。
lighttpd,thttpd,shttpd
國內絕大部分的web server不是IIS就是Apache，而論市場占有率，我認為Apache是大贏家了，至少是占據了半壁江山。
但 除了IIS/Apache外，其實我們有很多選擇，對于高負載/大并發的網站而言，高性能、輕量級的web server是一劑良藥。最近手頭一臺Server 的負載太高，居然將swap吃光導致機器非常緩慢，后來一查，原來是Apache耗掉了幾乎所有資源，當時apache進程已有9XX個了。
于是用輕量級的web server替換掉apache就進入了日程表。這里順帶介紹一下這些可選的對象：
lighttpd
官方主頁：www.lighttpd.net
Lighttpd是一個德國人領導的開源軟件，其根本的目的是提供一個專門針對高性能網站，安全、快速、兼容性好并且靈活的web server環境。具有非常低的內存開銷，cpu占用率低，效能好，以及豐富的模塊等特點。
lighttpd 是眾多OpenSource輕量級的web server中較為優秀的一個。支持FastCGI, CGI, Auth, 輸出壓縮(output compress), URL重寫, Alias等重要功能，而Apache之所以流行，很大程度也是因為功能豐富，在lighttpd上很多功能都有相應的實現了，這點對于apache的用 戶是非常重要的，因為遷移到lighttpd就必須面對這些問題。
實用起來lighttpd確實非常不錯，上文提到的apache overload的問題，用lighttpd就完全解決了。apache主要的問題是密集并發下，不斷的fork()和切換，以及較高（相對于 lighttpd而言）的內存占用，使系統的資源幾盡枯竭。而lighttpd采用了Multiplex技術，代碼經過優化，體積非常小，資源占用很低， 而且反應速度相當快。
利用apache的rewrite技術，將繁重的cgi/fastcgi任務交給lighttpd來完成，充分利用兩者的優點，現在那臺服務器的負載下降了一個數量級，而且反應速度也提高了一個甚至是2個數量級！
下面是他們官方站點上的一段話：
"lightTPD is the BEST webserver out there, much faster than apache and much much much more flexible/configurable/secure than tux, and its fcgi php support is simply unbeatable." thttpd
官方網站：http://www.acme.com/software/thttpd/
thttpd 是一個非常小巧的輕量級web server，它非常非常簡單，僅僅提供了HTTP/1.1和簡單的CGI支持，在其官方網站上有一個與其他web server（如Apache, Zeus等）的對比圖+Benchmark，可以參考參考。此外，thttpd 也類似于lighttpd，對于并發請求不使用fork()來派生子進程處理，而是采用多路復用(Multiplex)技術來實現。因此效能很好。
Thttpd 支持多種平臺，如FreeBSD, SunOS, Solaris, BSD, Linux, OSF等。對于小型web server而言，速度快似乎是一個代名詞，通過官方站提供的Benchmark，可以這樣認為：thttpd至少和主流的web server一樣快，在高負載下更快，因為其資源占用小的緣故。
Thttpd還有一個較為引人注目的特點：基于URL的文件流量限制，這對于下載的流量控制而言是非常方便的。象Apache就必須使用插件實現，效率較thttpd低。 shttpd
官方網站：http://shttpd.sourceforge.net/ Shttpd是另一個輕量級的web server，具有比thttpd更豐富的功能特性，支持CGI, SSL, cookie, MD5認證, 還能嵌入(embedded)到現有的軟件里。最有意思的是不需要配置文件！
由于shttpd可以嵌入其他軟件，因此可以非常容易的開發嵌入式系統的web server，官方網站上稱shttpd如果使用uclibc/dielibc(libc的簡化子集)則開銷將非常非常低。以下是其特點： Stand-alone server, or embeddable into existing C/C++ program
GET, POST, PUT, DELETE methods
CGI
SSL
Digest (MD5) authorization
Multiple (and user defineable) index files
Directory listing
Standard logging
Cookies
inetd mode
User-defineable mime types
No configuration files
No external dependencies 由于shttpd可以輕松嵌入其他程序里，因此shttpd是較為理想的web server開發原形，開發人員可以基于shttpd開發出自己的webserver！
下面是我翻譯的LiteSpeed Web Server官方的一篇文章。 圖片請參見...... http://www.litespeedtech.com/benchmark.html
幾種web server表現的對比：
被測試的web server 軟件
測試環境
測試結果
以小的靜態文件為測試基準
以CGI為基準
以FAST CGI為基準
以PHP腳本為基準：mod_php vs. FastCGI PHP
以Perl腳本為基準：mod_perl vs. lsperld
結論。 被測試的web server 軟件
下面幾種web server都包含在這次測試中。
Apache 1.3.33
Apache 2.0.52 (prefork mpm)
IIS 6.0
LiteSpeed 2.0 Standard
LiteSpeed 2.0 Professional
thttpd 2.25b
TUX 3.2
boa 0.94.14rc20
lighttpd 1.3.12
Aolserver 4.0.7
Mathopd 1.5p3
說明一下LSWS 是LiteSpeed Web Server的縮寫。
本來也很想把zeus和 sunone也放到這次基準測試中來，但是那些軟件的聲明不允許對對它們的測試結果進行公布。 測試環境
Network Switch: D-Link Gigabit Eight Ports Switch DGS-1008D
Server Hardware: Dell PowerEdge SC1600
CPU: Single Intel Xeon 2.4GHz/533FSB/512KB L2 Cache
memory: 256MB ECC PC2700
Hard Drive: 36GB 10K RPM SCSI drive Seagate ST336607LW
NIC: on board Intel PRO/1000 Gigabit Adapter
Server Software:
Fedora Core 3 with stock kernel 2.6.10-1.760
IIS 6.0 on Windows 2003 Enterprise
Web Server Configurations:
Apache 1.3.33
Apache 2.0.52
IIS 6.0 - default
LiteSpeed 2.0 Standard - default
LiteSpeed 2.0 Professional - default
thttpd
TUX 3.2 - default
boa
lighttpd
Aolserver
Mathopd
如果想知道他們當時的具體配置可以去原文中查看，Web Server Configurations: http://www.litespeedtech.com/benchmark.html 。 注意：LiteSpeed 和 lighttpd都支持在2.6內核中新的i/o 事件發送器sys_epoll()。但是有意思的是。我們發現這兩種server基準測試的結果還沒以前的標準時間發送器poll(),表現的好。
至少當我們通過網絡測試并發等級<=1000的時候，我們僅僅用poll()來做我們所有的測試。
結果可能會和在本地機上通過回路測試完全不同。 Client Hardware: MSI K7D
CPU: Dual Athlon MP 2000+/266FSB/256KB L2 Cache
memory: 1GB PC2100
Hard Drive: 36GB 1000RPM SCSI drive
NIC: Intel PRO/1000 Gigabit Adapater
Client Software:
OS: RedHat 8.0 with kernel 2.4.22smp
Test Tool: ApacheBench (ab) 1.3.33
測試結果：
每種情況運行3次，最好的結果被采納。服務器被重新啟動，當每次測試完一種web server軟件。
以小的靜態文件為測試基準
小的靜態頁面大小只有100 bytes。用小文件測試的原因是為了避免網絡帶寬瓶頸。我們只為了展示web server的表現，而不是內核。
Non-KeepAlive test: ab -n 100000 -c <concurrent level> http://<ip>:<port>/100.html
這兒必然有某種Anti-DoS特性在IIS 6.0中，當并發等級大于10（小于100）的時候它丟棄了所有的連接。 KeepAlive test: ab -n 100000 -c <concurrent level> -k http://<ip>:<port>/100.html
CGI 基準測試
一個簡單的c cgi腳本(echo)被用來在這里測試。它是C CGI/FCGI在fcgi 2.4包中 的例子。用來打印出所有的cgi環境變量。
CGI Test: ab -n 3000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
不知道為什么什么原因使thttpd's CGI在這表現如此差。
Fast CGI 基準測試
一個簡單的c++ cgi腳本(echocpp) 被用來這里測試。它是一個fcgi 2.4包中修改版本的c++ FCGI例子。它被修改成只產生一個恒定的響應。這個響應是162 byte在響應體中（response body）。從請求到請求發生改變的部分被去掉了，因為ab（ApacheBench）不喜歡變長響應體的響應。
Fast CGI Test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
PHP腳本基準測試: mod_php vs. FastCGI PHP
兩個簡單的php腳本被用來測試。一個是hello.php只 輸出hello world。另一個是phpinfo.php，只調用phpinfo()。這里都沒有配置操作碼加速器（opcode accelerator）。因為他們對這兩個簡單的php腳本沒有太大的影響。
hello.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/hello.php
phpinfo.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/phpinfo.php
Perl 腳本基準測試: mod_perl vs. lsperld
一個Hello World perl腳本，產生一個77 bytes的響應體。被用來測試。
Apache 2.0沒有測。因為在同一個服務器上既為 1.3又為2.0安裝mod_perl太麻煩了。
Apache 1.3 被配置成用 Apache::Registry去處理perl 腳本.
Lsperld 是一個Perl Fast CGI 腳本它可以運行CGI perl 腳本在一個 persistent Perl interpreter中, 就像 Apache mod_perl's Apache::Registry, 編譯perl 腳本，cached 到內存中。 hello.pl test: AB -n 10000 -c <concurrent level> http://<ip>:<port>/hello.pl
總結：
在以上的基準測試結果中我們得到了以下的結論。
Apache 1.3和 2.0的表現非常相近。2.0沒有什么優勢。我們沒有測試Apache 2.0的worker MPM。因為prefork MPM更有可能被用于Unix/Linux系統的應用。跟Apache比起來, LiteSpeed Web Server能快3-7倍當它處理靜態內容的時候。當處理動態內容的是時候能快50-100%，包括CGI, FastCGI, PHP and Perl.方式。
我們早期的測試表明，Apache的性能下降非常大，當distributed configuration override (.htaccess) 被設置為enabled。然而LiteSpeed web server幾乎不受影響。所以我們將能看到更大的差距在一個共享的主機環境中。 跟這些純粹的用戶區（land） 內容加速器像thttpd, boa 和mathopd比較起來, LiteSpeed Web Server 在處理靜態內容上有更好的表現。跟kernel內核內容加速器比較起來，TUX,由于在內核中的快捷和簡單的特性設置。LiteSpeed Web Server Pro在non-keep-alive測試中表現有點遜色。
這全部的LiteSpeed web server的表現，包括Standard 和 Professional版本，比其他所有被測試的web server軟件都好。
LiteSpeed Web Server 是一個多元（one-stop） 解決方案在高性能web服務環境中.
如果你真的想你的網站停止遭受各種各樣性能表現上的問題和在你現有的硬件上表現出最好的web服務的產出。你應該認真的考慮切換到LiteSpeed.。它將省去你所有在優化你的web各部分的時候所有頭疼的事情。因為我們已經為你做完了所有艱難的工作。
我的總結：
如果只有靜態頁面和圖片的話，可以用Zeus或者TUX，效率比apche高很多，尤其是TUX因為是和內核心結合的有較高的效率我認為是靜態內容server的最佳選擇，但他的限制是必須使用linux2.4以上的內核。我們的freebsd系統可能無法使用。 至于apache1.3和apache2.0對于理靜態內容的比較，和worker MPM 與 prefork MPM性能方面的比較，我還沒有一個權威的資料來說明。對于負載不是很高的站點，需要較高的穩定性的話，apache還是很好的選擇。 LiteSpeed Web Server的介紹我在這里沒有列出，從比較來看，他的綜合性能是不錯的。我可以給出一段他的描述：http://www.litespeedtech.com/
LiteSpeed web server is an Apache interchangeable, full-featured high performance, secure HTTP server specifically engineered from the ground up with security and scalability in mind. lighttpd,thttpd,shttpd的穩定性還沒有一個肯定的說法。
以后再對這個文檔進行補充。翻譯的不正確的地方歡迎指出，可以參看原文。RFID管理系統集成商 RFID中間件 條碼系統中間層 物聯網軟件集成
2. lighttpd,thttpd,shttpd
3. 幾種web server表現的對比
4. 我的總結 TUX
http://www.chinadesign.com.cn/NewsContents1.asp?id=3386
tux是一種有GPL（GNU General Public License ）許可的基于內核的Web服務器。 目前它還只能提供靜態的網頁服務，只有和內核區模塊，用戶區模塊，以及一般的用戶區Web服務器后臺一起應用的時候才提供動態的內容服務。一般用戶區的Web服務器不需要為了適應TUX而改變很多地方。然而，用戶區數據段代碼必須要有一個通向TUX的系統調用的接口。 雖然動態的內容服務現在增長的很迅速，但是也必須要提供靜態的內容服務。如，所有的圖片文件就都是靜態的。TUX能給在Linux的內核里提供非常高效率的靜態內容服務，就象在內核里運行的NFS網絡文件系統服務一樣。 TUX也有處理動態內容的功能。TUX模塊用網頁緩沖存儲動態內容的對象。當一個動態的請求到達的時候，一個TUX的模塊就發送會一個聯合 的動態請求并緩沖這個請求。這就是TUX的零拷貝緩存校驗的結構。（建議TUX模塊不許運行在用戶區，雖然他們也可以運行在內核區。） 這個新的動態內容的處理需要一個新的API接口。當前的CGI的API接口不能充分的用在TUX的API上。因此，當前的CGI程序為了使 用TUX就要修改當前的程序。如果CGI程序不需要增加TUX的速度的話，TUX也可以把它安一般的CGI來處理。要實現這個功能就要用TUX的CGI模 塊。TUX也可以處理復雜的CGI或是其他的請求，這要通過它把請求重定向到另外一個web服務器后臺程序，如Apache。也就是說，靜態的內 容，TUX模塊，老的CGI程序，以及為TUX Web服務器編寫的特定的程序都可以在TUX這個主服務器里運行。 一句話，TUX和其他的Web服務器的區別和TUX的好處包括： TUX是作為Linux的內核2.4.x或更高的一部分來運行的，另外一部分可以做為用戶區來運行。 TUX緩存部分的TCP校驗并用它們來加快網絡數據傳輸速度。 用一個特定的網絡卡，TUX可以從頁面緩存定向分散的DMA直接到網絡，這樣就避免了數據的拷貝。 當TUX不知道如何去處理一個請求或是接受到一個請求不能去運行的時候，它一般會把這個請求傳送到用戶區的Web服務器后臺去處理它。一個典型的用戶區Web服務器就是Apache。 2．TUX 2.0的新功能 TUX 2.0是從TUX 1.0升級成的，仍然保守著與用戶區模塊的兼容性。 增加的功能包括： 真正的零磁盤讀拷貝，TUX1.0是放到一個臨時的緩存里的。
生成網絡寫的零拷貝。
零拷貝解析。
其他新功能： 提高用戶去功能模塊的支持。
虛擬主機的支持，它不限制虛擬主機的數量。
CGI可以綁定到特定的進程
一些BUG的修復。 3．系統的基本需要 TUX需要基于2.4.x內核或是更高版本的系統。
基于X86的服務器。
交替的Web服務器如Apache來處理不知道的請求
當前的限制：
內核模塊只支持服務器端。
TUX只在x86的Linux平臺上測試過。
TUX能請求其他的Web服務器如Apache來處理請求。在當前的版本，它對回滾不是處理的很好。
lighttpd,thttpd,shttpd
國內絕大部分的web server不是IIS就是Apache，而論市場占有率，我認為Apache是大贏家了，至少是占據了半壁江山。
但 除了IIS/Apache外，其實我們有很多選擇，對于高負載/大并發的網站而言，高性能、輕量級的web server是一劑良藥。最近手頭一臺Server 的負載太高，居然將swap吃光導致機器非常緩慢，后來一查，原來是Apache耗掉了幾乎所有資源，當時apache進程已有9XX個了。
于是用輕量級的web server替換掉apache就進入了日程表。這里順帶介紹一下這些可選的對象：
lighttpd
官方主頁：www.lighttpd.net
Lighttpd是一個德國人領導的開源軟件，其根本的目的是提供一個專門針對高性能網站，安全、快速、兼容性好并且靈活的web server環境。具有非常低的內存開銷，cpu占用率低，效能好，以及豐富的模塊等特點。
lighttpd 是眾多OpenSource輕量級的web server中較為優秀的一個。支持FastCGI, CGI, Auth, 輸出壓縮(output compress), URL重寫, Alias等重要功能，而Apache之所以流行，很大程度也是因為功能豐富，在lighttpd上很多功能都有相應的實現了，這點對于apache的用 戶是非常重要的，因為遷移到lighttpd就必須面對這些問題。
實用起來lighttpd確實非常不錯，上文提到的apache overload的問題，用lighttpd就完全解決了。apache主要的問題是密集并發下，不斷的fork()和切換，以及較高（相對于 lighttpd而言）的內存占用，使系統的資源幾盡枯竭。而lighttpd采用了Multiplex技術，代碼經過優化，體積非常小，資源占用很低， 而且反應速度相當快。
利用apache的rewrite技術，將繁重的cgi/fastcgi任務交給lighttpd來完成，充分利用兩者的優點，現在那臺服務器的負載下降了一個數量級，而且反應速度也提高了一個甚至是2個數量級！
下面是他們官方站點上的一段話：
"lightTPD is the BEST webserver out there, much faster than apache and much much much more flexible/configurable/secure than tux, and its fcgi php support is simply unbeatable." thttpd
官方網站：http://www.acme.com/software/thttpd/
thttpd 是一個非常小巧的輕量級web server，它非常非常簡單，僅僅提供了HTTP/1.1和簡單的CGI支持，在其官方網站上有一個與其他web server（如Apache, Zeus等）的對比圖+Benchmark，可以參考參考。此外，thttpd 也類似于lighttpd，對于并發請求不使用fork()來派生子進程處理，而是采用多路復用(Multiplex)技術來實現。因此效能很好。
Thttpd 支持多種平臺，如FreeBSD, SunOS, Solaris, BSD, Linux, OSF等。對于小型web server而言，速度快似乎是一個代名詞，通過官方站提供的Benchmark，可以這樣認為：thttpd至少和主流的web server一樣快，在高負載下更快，因為其資源占用小的緣故。
Thttpd還有一個較為引人注目的特點：基于URL的文件流量限制，這對于下載的流量控制而言是非常方便的。象Apache就必須使用插件實現，效率較thttpd低。 shttpd
官方網站：http://shttpd.sourceforge.net/ Shttpd是另一個輕量級的web server，具有比thttpd更豐富的功能特性，支持CGI, SSL, cookie, MD5認證, 還能嵌入(embedded)到現有的軟件里。最有意思的是不需要配置文件！
由于shttpd可以嵌入其他軟件，因此可以非常容易的開發嵌入式系統的web server，官方網站上稱shttpd如果使用uclibc/dielibc(libc的簡化子集)則開銷將非常非常低。以下是其特點： Stand-alone server, or embeddable into existing C/C++ program
GET, POST, PUT, DELETE methods
CGI
SSL
Digest (MD5) authorization
Multiple (and user defineable) index files
Directory listing
Standard logging
Cookies
inetd mode
User-defineable mime types
No configuration files
No external dependencies 由于shttpd可以輕松嵌入其他程序里，因此shttpd是較為理想的web server開發原形，開發人員可以基于shttpd開發出自己的webserver！
下面是我翻譯的LiteSpeed Web Server官方的一篇文章。 圖片請參見...... http://www.litespeedtech.com/benchmark.html
幾種web server表現的對比：
被測試的web server 軟件
測試環境
測試結果
以小的靜態文件為測試基準
以CGI為基準
以FAST CGI為基準
以PHP腳本為基準：mod_php vs. FastCGI PHP
以Perl腳本為基準：mod_perl vs. lsperld
結論。 被測試的web server 軟件
下面幾種web server都包含在這次測試中。
Apache 1.3.33
Apache 2.0.52 (prefork mpm)
IIS 6.0
LiteSpeed 2.0 Standard
LiteSpeed 2.0 Professional
thttpd 2.25b
TUX 3.2
boa 0.94.14rc20
lighttpd 1.3.12
Aolserver 4.0.7
Mathopd 1.5p3
說明一下LSWS 是LiteSpeed Web Server的縮寫。
本來也很想把zeus和 sunone也放到這次基準測試中來，但是那些軟件的聲明不允許對對它們的測試結果進行公布。 測試環境
Network Switch: D-Link Gigabit Eight Ports Switch DGS-1008D
Server Hardware: Dell PowerEdge SC1600
CPU: Single Intel Xeon 2.4GHz/533FSB/512KB L2 Cache
memory: 256MB ECC PC2700
Hard Drive: 36GB 10K RPM SCSI drive Seagate ST336607LW
NIC: on board Intel PRO/1000 Gigabit Adapter
Server Software:
Fedora Core 3 with stock kernel 2.6.10-1.760
IIS 6.0 on Windows 2003 Enterprise
Web Server Configurations:
Apache 1.3.33
Apache 2.0.52
IIS 6.0 - default
LiteSpeed 2.0 Standard - default
LiteSpeed 2.0 Professional - default
thttpd
TUX 3.2 - default
boa
lighttpd
Aolserver
Mathopd
如果想知道他們當時的具體配置可以去原文中查看，Web Server Configurations: http://www.litespeedtech.com/benchmark.html 。 注意：LiteSpeed 和 lighttpd都支持在2.6內核中新的i/o 事件發送器sys_epoll()。但是有意思的是。我們發現這兩種server基準測試的結果還沒以前的標準時間發送器poll(),表現的好。
至少當我們通過網絡測試并發等級<=1000的時候，我們僅僅用poll()來做我們所有的測試。
結果可能會和在本地機上通過回路測試完全不同。 Client Hardware: MSI K7D
CPU: Dual Athlon MP 2000+/266FSB/256KB L2 Cache
memory: 1GB PC2100
Hard Drive: 36GB 1000RPM SCSI drive
NIC: Intel PRO/1000 Gigabit Adapater
Client Software:
OS: RedHat 8.0 with kernel 2.4.22smp
Test Tool: ApacheBench (ab) 1.3.33
測試結果：
每種情況運行3次，最好的結果被采納。服務器被重新啟動，當每次測試完一種web server軟件。
以小的靜態文件為測試基準
小的靜態頁面大小只有100 bytes。用小文件測試的原因是為了避免網絡帶寬瓶頸。我們只為了展示web server的表現，而不是內核。
Non-KeepAlive test: ab -n 100000 -c <concurrent level> http://<ip>:<port>/100.html
這兒必然有某種Anti-DoS特性在IIS 6.0中，當并發等級大于10（小于100）的時候它丟棄了所有的連接。 KeepAlive test: ab -n 100000 -c <concurrent level> -k http://<ip>:<port>/100.html
CGI 基準測試
一個簡單的c cgi腳本(echo)被用來在這里測試。它是C CGI/FCGI在fcgi 2.4包中 的例子。用來打印出所有的cgi環境變量。
CGI Test: ab -n 3000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
不知道為什么什么原因使thttpd's CGI在這表現如此差。
Fast CGI 基準測試
一個簡單的c++ cgi腳本(echocpp) 被用來這里測試。它是一個fcgi 2.4包中修改版本的c++ FCGI例子。它被修改成只產生一個恒定的響應。這個響應是162 byte在響應體中（response body）。從請求到請求發生改變的部分被去掉了，因為ab（ApacheBench）不喜歡變長響應體的響應。
Fast CGI Test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
PHP腳本基準測試: mod_php vs. FastCGI PHP
兩個簡單的php腳本被用來測試。一個是hello.php只 輸出hello world。另一個是phpinfo.php，只調用phpinfo()。這里都沒有配置操作碼加速器（opcode accelerator）。因為他們對這兩個簡單的php腳本沒有太大的影響。
hello.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/hello.php
phpinfo.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/phpinfo.php
Perl 腳本基準測試: mod_perl vs. lsperld
一個Hello World perl腳本，產生一個77 bytes的響應體。被用來測試。
Apache 2.0沒有測。因為在同一個服務器上既為 1.3又為2.0安裝mod_perl太麻煩了。
Apache 1.3 被配置成用 Apache::Registry去處理perl 腳本.
Lsperld 是一個Perl Fast CGI 腳本它可以運行CGI perl 腳本在一個 persistent Perl interpreter中, 就像 Apache mod_perl's Apache::Registry, 編譯perl 腳本，cached 到內存中。 hello.pl test: AB -n 10000 -c <concurrent level> http://<ip>:<port>/hello.pl
總結：
在以上的基準測試結果中我們得到了以下的結論。
Apache 1.3和 2.0的表現非常相近。2.0沒有什么優勢。我們沒有測試Apache 2.0的worker MPM。因為prefork MPM更有可能被用于Unix/Linux系統的應用。跟Apache比起來, LiteSpeed Web Server能快3-7倍當它處理靜態內容的時候。當處理動態內容的是時候能快50-100%，包括CGI, FastCGI, PHP and Perl.方式。
我們早期的測試表明，Apache的性能下降非常大，當distributed configuration override (.htaccess) 被設置為enabled。然而LiteSpeed web server幾乎不受影響。所以我們將能看到更大的差距在一個共享的主機環境中。 跟這些純粹的用戶區（land） 內容加速器像thttpd, boa 和mathopd比較起來, LiteSpeed Web Server 在處理靜態內容上有更好的表現。跟kernel內核內容加速器比較起來，TUX,由于在內核中的快捷和簡單的特性設置。LiteSpeed Web Server Pro在non-keep-alive測試中表現有點遜色。
這全部的LiteSpeed web server的表現，包括Standard 和 Professional版本，比其他所有被測試的web server軟件都好。
LiteSpeed Web Server 是一個多元（one-stop） 解決方案在高性能web服務環境中.
如果你真的想你的網站停止遭受各種各樣性能表現上的問題和在你現有的硬件上表現出最好的web服務的產出。你應該認真的考慮切換到LiteSpeed.。它將省去你所有在優化你的web各部分的時候所有頭疼的事情。因為我們已經為你做完了所有艱難的工作。
我的總結：
如果只有靜態頁面和圖片的話，可以用Zeus或者TUX，效率比apche高很多，尤其是TUX因為是和內核心結合的有較高的效率我認為是靜態內容server的最佳選擇，但他的限制是必須使用linux2.4以上的內核。我們的freebsd系統可能無法使用。 至于apache1.3和apache2.0對于理靜態內容的比較，和worker MPM 與 prefork MPM性能方面的比較，我還沒有一個權威的資料來說明。對于負載不是很高的站點，需要較高的穩定性的話，apache還是很好的選擇。 LiteSpeed Web Server的介紹我在這里沒有列出，從比較來看，他的綜合性能是不錯的。我可以給出一段他的描述：http://www.litespeedtech.com/
LiteSpeed web server is an Apache interchangeable, full-featured high performance, secure HTTP server specifically engineered from the ground up with security and scalability in mind. lighttpd,thttpd,shttpd的穩定性還沒有一個肯定的說法。
以后再對這個文檔進行補充。翻譯的不正確的地方歡迎指出，可以參看原文。RFID管理系統集成商 RFID中間件 條碼系統中間層 物聯網軟件集成