Apache、lighttpd、Nginx用哪個搭建高性能服務器

　　對于Web高性能服務器上的選擇，這個是很多人頭痛的問題。其實Apache、lighttpd、Nginx都用他們優點，在什么情況下我們如何去選擇適合自己的Web高性能服務器，如何去搭建一個適合自己的架構環境，這個是一個很麻煩的事情。接下來，在ADC 2012(Alibaba Developer Conference 2012)大會上，51CTO記者有幸采訪到了一淘數據平臺與產品部技術專家——清無(花名)，為我們解讀Nginx_lua的一些優勢及劣勢，以及在高性能服務器上的選擇。

　　首先讓我們來了解一下Nginx_lua的設計指導思想：

　　1、基于Nginx 快速開發高性能、大并發的網絡服務。

　　2、提供“同步非阻塞” 的I/O 訪問接口簡化I/O 多路復用體系中的業務邏輯開發：

　　■“同步”的主體是用戶代碼與其發起的I/O 請求處理流程之間的時序關系，意即I/O 請求處理完成前用戶代碼將一直掛起。

　　■“非阻塞”的主體是服務進程，意即I/O 請求的處理不會導致服務進程阻塞等待，而是可以繼續處理其他請求的用戶邏輯。

　　Nginx的特點是占有內存少，并發能力強，事實上nginx的并發能力確實在同類型的網頁伺服器中表現較好。目前中國大陸使用nginx網站用戶有：新浪、網易、 騰訊，另外知名的微網志Plurk也使用Nginx。

　　Nginx服務器及Lua版本的選擇

　　1)Nginx高性能開源WEB服務器的選擇

　　清無是在08年開始接觸Nginx服務器的，當時高性能的開源WEB服務器還有lighttpd，那么一淘網技術專家清無為什么會選擇Nginx 呢?Nginx哪方面比較有它的優勢?清無介紹說，lighttpd和Nginx的比較中，有一個很明顯的缺點就是lighttpd的模塊機制設計的很不好，lighttpd的模塊機制過多的把模塊本身的請求處理邏輯和底層的網絡事件的處理組合在一起，所以不像Nginx的模塊結構這么清晰，當然 Nginx的模塊設計很大程度上也借鑒了Apache的這種模塊設計，所以這塊有一個先天的優勢。當時其實他最早接觸lighttpd，然后Nginx出來以后，就對比它們模塊結構上的差異后，覺得Nginx似乎更有優勢一些。實測對于我們這種網絡I/O密集型的應用來說，只要不是你實現的這個邏輯有多大缺陷，其實在放lighttpd或者Nginx差別不是特別大。

　　在比較選擇的過程中，首先從架構出發，如果有問題的話無論你實現如何它都是有問題的，所以我的比較首先在架構搭建上，每連接或者每請求單線程單進程這種服務模型，直接就被刷掉，肯定不可能做到很高的服務能力。余下來清一色的都是基于RO多路的這種結構體系，那么在這個體系上我們才去檢驗，實際上拿一個IPP的請求來壓測看它實現的質量如何，通常來說這部分一旦架構體系決定以后，實測這個性能差異不是特別的大，除非說是某個特性一個實現另一個沒實現這種情況，我們測出來的差異通常是在10%-20%上下波動而已。

　　2)Lua版本的選擇

　　在小編與清無的交流中了解到目前一淘網所使用lua的版本是5.1.2，當小編提出是否版本越高性能越強時，清無則認為不太對。對于lua來說每一個版本的變化意味著它將加入新的語法元素或者變更了內部的一些實現的方式。嚴格意義上并不說明它的性能就好，比如對5.2和5.1來說，不管對于環境表或者其它的一些機制的修改上面，嚴格的來說他都是一種新的語言了。所以目前來說遷移到5.2最大的障礙其實還是5.2里面對于底層接口的這種概念的變化。因為5.1里面對于一些方面下了很多工夫，然后使用它的全局表加環境表這種機制。但是5.2里面徹底取消了全局表的概念，也取消了CU級別上一系列對環境表操作的接口，對我們來說肯定是不能平滑的遷移到5.2，如果有這個需求的話，我們可以做，但目前還沒有看到這個需求。另外一個阻礙我們升級版本號的問題是 Lua JIT，lua JIT的性能比標準的lua要高很多，所以深層里面我們通常用JIT，但是luaJIT目前對lua5.2的支持并不是那么緊，它目前還是以5.1為主，所以這塊我沒可能較長的時間跟著lua JIT的腳步來。

　　在一淘網的應用中，清無介紹說，Nginx_lua主要應用在兩塊地方，一塊是傳統的一淘數據庫量子統計店鋪經，數據接口部分完全是用Nginx_lua來做。另一塊是一淘的廣告部門有一部分數據接口也使用著Nginx_lua。

　　Nginx_lua的性能測試比較

　　其實也有很多人一直還在使用Nginx_php這種組合搭配，對于Nginx_lua組合的優勢在哪里呢?清無介紹說，Nginx+php之間是要有進程之間通信的，這樣以來基礎的性能開銷就很大。lua是嵌在Nginx進程內部的，它不需要有兩套進程在那里獨立工作。所以這塊從結構上來說就有決定性的優勢在里面。再加上線程之間通訊的時候需要大量的反序列化和序列化的工作，然后兩套進程帶來額外情況是更多的進程更多的切換開銷，所以單機上面 Nginx_php要比Nginx_lua要低很多。但是相對來說仍然要回到我們做什么事情上面，因為Nginx_lua目前最大的劣勢就是周邊的模塊相當的不健全，我們需要大量的時間來積累這些模塊。php積累了十幾年的時間了，如果說你對性能的要求并不是那么高，我的并發數就是幾十，那么你用php就是最合適的。但是如果像一淘數據的數據接口，機器數就那么一點，因為我的大量成本在MySQL集群上面，它是這塊的主力，那么對外的數據接口我希望盡可能降成本，并發數又非常大，php肯定是不行，那么我們就要選擇Nginx_lua。但這塊的話對模塊的劣勢看起來不是那么大，因為它的邏輯相對來說較為固定，我們可以忍受這樣的成本，我們去為這個邏輯來定制一些模塊。

　　從上面的兩張性能測試圖中我們總結Nginx_lua的適用場景：

　　網絡I/O 阻塞時間遠高于CPU 計算占用時間、同時上游資源非瓶頸(可伸縮)的網絡應用，如高性能網絡中間層、HTTP REST 接口服務等;

　　期望簡化系統架構，讓服務向Nginx 同質化的Web 站點;

原文轉自：http://www.anti-gravitydesign.com