51CTO專訪清無：Nginx_lua的應用及性能對比

51CTO專訪清無：Nginx_lua的應用及性能對比

2012-07-13 10:57 小林 51CTO.com 字號：T | T

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

AD：乾貨來了,不要等！WOT2015 北京站演講PPT開放下載！

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

 

王曉哲：花名清無，一淘網技術專家。任職於一淘數據部，負責量子恆道總體技術架構搭建。對海量數據處理、高性能高可用的Web服務相關技術有濃厚興趣。

清無你好，lua咱們都知道是一種嵌入式的腳本語言，而它最著名的是應用在暴雪的魔獸世界和網易的大話西遊中。那麼在淘寶上的應用lua主要是應用在那塊？

清無：目前在一淘網這邊Nginx_lua主要應用在兩塊地方，一塊是傳統的一淘數據庫量子統計店鋪經，數據接口部分徹底是用Nginx_lua來作。另外一塊是一淘的廣告部門有一部分數據接口也使用着Nginx_lua。

具個人瞭解，你開始接觸nginx應該是2008年的。在08年時，不少高性能的WEB服務器也很是多，好比apache、lighttpd等等。這些都是高性能的開源服務器，你選擇nginx是由於什麼？它那方面比較吸引你？

清無：08的時候高性能WEB服務器除了Nginx之外其實只有lighttpd是開源的，lighttpd和Nginx比較的話有一個很明顯的缺點是lighttpd的模塊機制設計的很很差，lighttpd的模塊機制過多的把模塊自己的請求處理邏輯和底層的網絡事件的處理組合在一塊兒，因此不像Nginx的模塊結構這麼清晰，固然Nginx的模塊設計很大程度上也借鑑了Apache的這種模塊設計，因此這塊有一個先天的優點。當時其實我最先接觸lighttpd，而後Nginx出來之後，就對比它們模塊結構上的差別後，以爲Nginx彷佛更有優點一些。實測對於咱們這種網絡I/O密集型的應用來講，只要不是你實現的這個邏輯有多大缺陷，其實在放lighttpd或者Nginx差異不是特別大。

Nginx的優點你剛剛也講了，你有沒有哪nginx和其餘的開源web服務器作過一些性能比較？能夠跟咱們網友進行一些分析。

清無：比較的話是這樣，首先架構若是有問題的話不管你實現如何它都是有問題的，因此個人比較首先在架構搭建上，每鏈接或者每請求單線程單進程這種服務模型，直接就被刷掉，確定不可能作到很高的服務能力。餘下來清一色的都是基於RO多路**的這種結構體系，那麼在這個體系上咱們纔去檢驗這個*****，實際上拿一個IPP的請求來壓測看它實現的質量如何，一般來講這部分一旦架構體系決定之後，實測這個性能差別不是特別的大，除非說是某個特性一個實現另外一個沒實現這種狀況，咱們測出來的差別一般是在10%-20%上下波動而已。

lua目前最高的版本是5.2，大家如今使用的是哪一個版本？

清無：咱們如今使用的是5.1.2，後面那個是補丁號。

若是我認爲它的版本越高，性能越強你認爲對嗎？

清無：呵呵，不太對。對於lua來講每個版本的變化意味着它將加入新的語法元素或者變動了內部的一些實現的方式。嚴格意義上並不說明它的性能就好，好比對5.2和5.1來講，無論對於環境表或者其餘的一些機制的修改上面，嚴格的來講他都是一種新的語言了。因此目前來講遷移到5.2最大的障礙其實仍是5.2裏面對於底層接口的這種概念的變化。由於5.1裏面對於//造成隔離//方面下了不少工夫，而後使用它的全局表加環境表這種機制，可是5.2裏面完全取消了全局表的概念，也取消了CU級別上一系列對環境表操做的接口，對咱們來講確定是不能平滑的遷移到5.2，若是有這個需求的話，咱們能夠作，但目前尚未看到這個需求。另一個阻礙咱們升級版本號的問題是LuaJIT，luaJIT的性能比標準的lua要高不少，因此//深層//裏面咱們一般用JIT，可是luaJIT目前對lua5.2的支持並非那麼緊，它目前仍是以5.1爲主，因此這塊我沒可能較長的時間跟着luaJIT的腳步來。

據我瞭解lua的特色是體積小、快速、簡單，做爲獨立編程並非它的主要使用方式，由於它不像java那樣有一個完善的庫，必須嵌入到其餘的大型語言中才能發揮出它的併發能力和靈活性。大家目前的主語言是什麼？

清無：實際上咱們是分場景，根據具體的業務場景來選擇最合適的語言。對一淘數據庫來講像Java，PHP，C++和lua都用。

在個人印象中不少人仍是選擇nginx+php這種組合搭配，你的選擇是nginx+lua，那麼nginx+lua比和php的組合優點在哪裏？

清無：首先，Nginx+php之間是要有進程之間通訊的，這樣以來基礎的性能開銷就很大。lua是嵌在Nginx進程內部的，它不須要有兩套進程在那裏獨立工做。因此這塊從結構上來講就有決定性的優點在裏面。再加上線程之間通信的時候須要大量的反序列化和序列化的工做，而後兩套進程帶來額外狀況是更多的進程更多的切換開銷，因此單機上面Nginx_php要比Nginx_lua要低不少。可是相對來講仍然要回到咱們作什麼事情上面，由於Nginx_lua目前最大的劣勢就是周邊的模塊至關的不健全，咱們須要大量的時間來積累這些模塊。php積累了十幾年的時間了，若是說你對性能的要求並非那麼高，個人併發數就是幾十，那麼你用php就是最合適的。可是若是像一淘數據的數據接口，機器數就那麼一點，由於個人大量成本在MySQL集羣上面，它是這塊的主力，那麼對外的數據接口我但願儘量降成本，併發數又很是大，php確定是不行，那麼咱們就要選擇Nginx_lua。但這塊的話對模塊的劣勢看起來不是那麼大，由於它的邏輯相對來講較爲固定，咱們能夠忍受這樣的成本，咱們去爲這個邏輯來定製一些模塊。

你認爲目前nginx+lua能知足你如今的需求嗎？有沒有嘗試或尋找其餘最佳的搭檔？

清無：對於咱們數據接口的這部分需求是徹底能夠知足的，至於其餘的需求咱們還要具體發現，尋找最佳決解方案。由於在計算機行業沒有一招吃遍天這種事。

做爲一名技術架構師，在性能這塊你認爲到何處爲止？仍是無止境的追求？

清無：這個要看咱們是在作生意仍是在我的事情，若是是在公司，好比在具體的事情上面，而後是一個團隊協做的狀況下，那麼盲目的追求性能的極限是一個不合適的行爲，由於你的追求是要付出相應的成本和開銷的，而每每在一個企業的環境裏面這個是不可容忍的。最合適的架構每每是針對你去解決問題的那個架構，而不是去追求效率最高的架構。因此咱們具體在企業裏面作項目的時候，顯然適可而止是最好的。蓋過了你這個用戶的最大需求你就不必去付出更多的精力來作，由於其餘的問題有不少，你不必停留在性能這個問題上，性能只是其中的一個問題，在一個問題上不必投入太大的精力。可是，從開發人員我的的角度來講，追求性能的極限是一個很好的想法和行爲，由於開發者本身對性能極限的追求體現出對完美的追求，對於完美的追求意味着它能夠從上層到底層的專研，而專研是提高我的素質最有效的動力。因此是分開來看這個問題。

你剛剛在大會上也講了一些nginx lua的優點和劣勢，能不能在這裏也給咱們網友分享一些？

清無：剛纔也說了一個是周邊模塊不完善，不健全。若是你用到的這個東西比較複雜的時候可能生產力上不去，目前Nginx_lua最適合的人員是數據接口層，以及全部的網絡中間層，你須要最求併發，高性能的網絡中間層。由於它自己的邏輯相對來講比較簡單，或者徹底用lua自己就能夠變現出來，這個用起來收效比例是最大的。那麼若是你目前要作一個複雜的WEB訪問站，有大量模板要套，有大量的複雜邏輯嵌在裏面，而後要訪問mail要訪問其餘服務的話，目前來講我以爲仍是php或者其餘比較成熟的語言。就咱們目前應用來講也是這樣，中間層會大量的使用lua，可是前端展示層的話要麼所有移到瀏覽器上面用JS+模板的形式來實現，要麼就是用PHP這樣來作。另外的劣勢就是調試的輔助工具不太多，由於高級點的php程序員會每每會使用XDebug或者其它的調試工具，能夠單步調試，在線調試。跟php相比目前還欠缺這樣的一個機制。到時候咱們會仿照XDebug 去實現DPT V2協議，咱們實現兼容DPT V2這樣的一種機制內連到Nginx_lua裏面，那樣Nginx_lua也能夠單步調試。到時候咱們也會分享給你們。